What agents are — and aren't

​

If you remember one thing

For seventy years, most software worked like rails: a developer wrote every step in advance. Same input, same path, same output — predictable by design, but inflexible when reality diverges. An AI agent works more like a driver: you hand it a destination, not a route. It reads the situation, decides the next move, adapts when things change, and stops when the goal is met. Everything in XSpada Agents is built around that shift — and the engineering it takes to point a driver at the right destination and trust how it gets there.

​

From writing the steps to setting the goal

The same job can be approached two ways. Notice where the judgment lives. In XSpada, Actions often play the “rails” role for steps that must be guaranteed (send this email, update this field). Agents play the “driver” role where open-ended judgment pays off (triage this inbox, draft a reply in our voice, research this topic). The best systems mix both deliberately.

​

What an agent is not

Most confusion about agents comes from four mix-ups.

​

Not a mind

An agent does not understand, want, or know things the way a person does. It produces the next most plausible response given what it has been shown. Useful — but not a colleague with beliefs.

​

Not magic, and not the model alone

The model (the AI engine) is one part. An agent is the model plus the scaffolding around it: instructions, context, tools, a loop, and limits. Drop the scaffolding and you have a chatbot, not an agent. In XSpada, that scaffolding is what you configure: system prompt, Focuses, linked files, assigned Actions, versions, and the Lab.

​

Not deterministic

Ask the same question twice and you may get two different routes. That flexibility is the point — but “it worked once” is not the same as “it works.” Test in the Lab, use versions, and review conversations in Chat Review.

​

Not reliable by default

Reliability is engineered in — with guardrails, good context, deterministic Actions where mistakes are expensive, and human review where autonomy is risky. Out of the box, an agent is capable and confident, which is not the same as correct.

​

What an agent actually is: a loop with a goal

Strip away the hype and every agent is the same simple cycle, repeated until the job is done:

1. Observe — read the goal and current context (instructions, linked files, conversation so far, tool results).
2. Think — decide the next best action.
3. Act — use a tool, take a step, or reply.
4. Repeat — until the goal is met or the agent stops.

The model is not called once. It is called over and over, each time seeing the results of its last action. That loop is the engine behind every agent conversation in XSpada — from a quick Chat question to a multi-step research session that creates artifacts.

​

The atom: model + prompt

Before agents, harnesses, and fleets — there is one irreducible unit. Because the engine cannot be changed at runtime and forgets between calls, the prompt must carry: who the agent should be, what it knows for this task, what it is allowed to do, and what is being asked right now.

​

System prompt vs. user message

Same text channel, very different roles — like a driver’s standing training versus today’s specific trip. The system prompt is a strong guide, not a hard wall. A well-built agent usually follows it, but it can be talked around. For behaviors that absolutely must hold, use deterministic Actions or approval steps in Tracks — not instructions alone.

​

The prompt stack (and the budget)

Every time the model is called, several layers are assembled into one block of text:

• System prompt — role, rules, boundaries
• Tool definitions — what actions are available
• Retrieved context — linked files, registry data, search results
• History — what has happened in this conversation
• User message — the request being answered now

There is only so much room — the context window. Deciding what earns a place, and what gets left out, is one of the most important jobs in building an agent. XSpada shows context usage on the agent detail view so you can see when instructions and linked files are crowding out conversation space.

​

Three kinds of engineering

You cannot change the model. All the craft lives in three levers around it: Rule of thumb: if the agent lacks information, fix context. If it has the information but uses it wrong, fix the prompt. If it cannot take the action you need, fix tools (Focus or assigned Actions).

​

Rails vs. judgment

Every part of an agent sits on a spectrum — from hard-coded and guaranteed to left to the model’s judgment. Good agents are not “as autonomous as possible.” They are autonomous exactly where it pays, and rigid everywhere else.

​

The harness: what XSpada builds for you

A model alone cannot do anything useful. The harness is the vehicle around the engine — and when people say “we built an agent,” they usually mean they built a harness pointed at a model. XSpada’s harness includes:

• The loop — observe, think, act, repeat until done
• Memory — conversation history and linked context re-supplied each turn
• Tools — Focuses and Actions the agent can call
• Guardrails — assigned Action limits, Track approvals, version control
• Recovery — error handling when a step fails
• Observability — Chat Review, version history, artifact records

Your job in Agent Manager is configuring the destination (goal, instructions, context, tools) and choosing how much to trust the driver versus laying down rails elsewhere in XSpada.

​

One agent vs. many

A single well-built agent with the right Focus and context handles most business jobs. Add a second agent only when one genuinely cannot cope — distinct phases needing different skills, too many tools for one context window, or a deliberate propose-and-review split. In XSpada, Tracks and Actions often coordinate humans and agents without building complex multi-agent systems. An agent overseer on a track, an agent node in an Action, and a specialist agent in Chat can be enough.

​

Six questions before you build

Before configuring an agent, get clear on:

1. What’s the goal, in one sentence? If you cannot say it crisply, the agent cannot pursue it.
2. What must never happen? These become Actions or Track gates — not prompt wishes.
3. What context does it need, and from where? If the data does not exist or is not reachable, stop here.
4. What actions must it take? Reads are easy; changes to the world need guardrails.
5. How will you know it’s working? Test in the Lab; review in Chat Review.
6. What’s the cost of being wrong? Sets how much autonomy vs. human review is wise.

​

Where to go next

If you would like something unique to your business or have a unique issue, use XSpada Evolve or ask a XSpada rep.