An agent is easy to build. A workforce of agents that can run every day, inside a real business, without someone watching every step, is a different engineering problem. Most of the project’s architecture exists to answer one question: when an agent does something, can we explain why, and can we trust it to do it again?
The anatomy of an agent
Every agent in the project is built from the same four parts:
- A role. Plain-language instructions describing the job, the tone, what good work looks like and when to escalate. This is versioned like code.
- Tools. The specific actions the agent can take, such as looking up an order, updating a record, sending a draft for approval or checking a roster. Each tool has a typed input, a clear description and its own permission level.
- Memory. The context the agent needs: the current task, relevant history, and knowledge retrieved from the business’s own documents.
- A policy. What the agent may do on its own, what needs approval and what it must never do. The policy is enforced by the platform, not left to the model’s judgment.
Keeping these parts separate is what makes the system maintainable. You can improve a role’s instructions without touching its permissions, or add a tool without rewriting the role.
Work comes in as tasks
Agents don’t sit in a chat loop waiting for messages. Work arrives as tasks from several sources: an incoming email or support ticket, a webhook from another system, a schedule (the Monday report) or a request from a person or another agent.
A coordinator looks at each task, decides which role should handle it and puts it on that agent’s queue. Simple tasks go straight to one agent. Larger ones get broken into steps. For example, “a staff member called in sick for tomorrow” might become:
- the workforce agent finds who could cover,
- a person approves the choice,
- the agent confirms with the replacement and updates the roster,
- the reporting agent notes the change for the week’s summary.
Every task has a state (queued, running, waiting for approval, done or failed), so nothing silently disappears.
Tools are the real interface
The quality of an agent depends more on its tools than on its prompt. Early on, we gave agents broad, generic tools like “call this API” or “run this query”. They worked in testing and caused trouble in production, because the model had to figure out the details every time.
The project moved to narrow, purpose-built tools. “Find available staff for a shift” instead of “query the database”. “Draft a reply to this ticket” instead of “send an email”. Narrow tools are easier for the model to use correctly, easier to permission and much easier to test.
Connections to outside systems such as helpdesks, CRMs, calendars and HR platforms sit behind a connector layer. Agents never see credentials. They call a tool, and the platform makes the call on their behalf, with the business’s own access rules applied.
Memory and knowledge
Agents need three kinds of memory:
- Working memory for the task in front of them: the ticket, the conversation, the steps taken so far.
- History for the people and records involved: previous tickets from this customer, recent changes to this roster.
- Knowledge from the business’s own documents, such as policies, product information and procedures, retrieved at the moment it’s needed instead of stuffed into every prompt.
Retrieval is scoped by role and by permission. The support agent can search the support knowledge base, but it can’t search HR documents, even by accident.
Picking the right model for each step
Not every step needs the most capable model. Routing a task, classifying a ticket or pulling a date out of an email are fast, cheap jobs. Planning a multi-step task or writing a careful reply to an upset customer are not. The platform chooses a model per step, which keeps costs predictable without lowering quality where it matters.
Seeing what happened
Every task produces a trace: the inputs, each model call, each tool call with its arguments and result, each approval and the final outcome. Traces are how we debug, how we build test cases and how a business owner answers the question “why did the agent do that?”
If you can’t see it, you can’t trust it, and if you can’t trust it, nobody will let it do real work.