How AR Labs builds an AI agent: from a job description to a running agent

This page describes how AR Labs builds an AI agent for a business: the sequence from a description of the job to an agent running in the business, what the client approves at each phase, and the document each phase leaves behind. An AI agent is a language model run in a loop with tools, so it can act, not only reply. The sequence is the one we follow for our own agents, set onto the phases of our client delivery framework so that each phase ends at a gate the client controls. We have built and run our own agents and a public voice agent, Salesbot; we have not yet delivered an agent to a client, and this page describes how we would.

The components named here are described in the guide to building an AI agent and the component reference.

Why the work is phased

An agent is easy to demonstrate and hard to keep useful. The failures that matter appear late: an agent that does well in a trial decides something it should not, drifts from its job over weeks, or cannot be restarted by anyone but its builder. Phasing moves those questions forward. Each phase answers one of them in writing before the next begins, and each leaves something the client keeps if the work stops there.

Phase 1: Discover the job

Framework phase: Discover.

We start from the work, not the technology. We map the workflow the agent would join as it actually runs, using the method in how to map a business process before automating it: recordings of real work, a log kept separate from interpretation, counts of what goes wrong, and the decisions that must stay with a person. Then we test whether the job needs an agent at all. Many jobs are better served by a form, a configured tool or a script, and if so, we say so.

The client approves the job in one sentence and an outcome statement in the framework's form: "By implementing [solution], we will [action] [metric] from [X] to [Y], resulting in [business value]."

It leaves a workflow map, the outcome statement, and a recommendation on whether an agent is the right tool.

Phase 2: Define the role and authority

Framework phase: Define.

We write the agent's role as a job description: standing responsibilities, the outcome it is judged on, and the division of work with the people it serves. For our own marketing manager agent we drew the duties from published descriptions of the job before deciding what the agent should hold, and fixed one division: the person writes, the agent researches, recommends and measures. Then the authority table: what the agent may do alone, what needs a person's yes, and what it may never do.

The client approves the role and each line of the authority table. Every line becomes either a check, an approval or an instruction in later phases, so the table is agreed before any design.

It leaves a role document and an authority table.

Phase 3: Design the components

Framework phase: Define, with decision records starting here.

We choose the runtime and how the agent lives (started on request, always on, scheduled, or one run per request), its instructions, skills and tools, its memory and task store, its channels and its gates. Each consequential choice is written as a decision record: the decision, its context, the options rejected and the consequences. We prefer what already exists: a runtime's own mechanisms, a published skill library installed whole, a task tracker the business already uses.

The client approves each decision that limits later work, such as where the agent runs, what accounts it can reach, and which of its actions need approval.

It leaves a design record with one page per decision and a diagram of the agent and the systems around it.

Phase 4: Prototype on real work

Framework phases: Prototype and Validate.

We build the smallest version that can do one real piece of the job, and test it against a baseline: the way the work is done today, or a simple rule. We write test scenarios from real cases, including the awkward ones found in discovery, and keep any session that goes wrong as a new scenario. Each check is marked as one a machine can make or one a person must, because some things, such as whether a reply reads well to a customer, need a person. Results are judged against the outcome in the role, not by reading transcripts.

The client approves going on or stopping, on the evidence. If the agent does not beat the baseline, the recommendation is to stop or to choose a simpler form.

It leaves a test scenario set and its results, which later become the regression suite.

Phase 5: Build

Framework phase: Build.

We build the agent's workspace: its instructions, skills, records, task store, channels and checks. The gates are built here: hooks (scripts run automatically around an agent's action that can block it) for each "never" in the authority table, approval steps for each "with a person's yes", and evidence of completion for its tasks. Code goes through our own coding pipeline: a spec for each change, tests first, review by a model from a different vendor, and a person's merge.

The client approves each change at the merge, and the scenario results before the agent is used for real.

It leaves the agent's versioned workspace, its hooks and checks, and passing scenarios.

Phase 6: Hand over

Framework phase: Launch.

We write the operating guide: how the agent is started, restarted and updated; who may change its settings and who may change its instructions; where its records live; how to test that its channels work; and what to check before calling it running unattended. On our own resident agent, an authorised operator changes service settings and credentials, keeping a backup first, while changes to the agent's instructions arrive as briefs that the agent installs itself. A channel counts as working only when the agent answers a test with substance.

The client approves going live, who operates the agent, and the access it is granted.

It leaves an operating guide and a record of the access granted.

Phase 7: Operate and improve

Framework phase: Evolve.

A running agent needs keeping on course. We review its work against the outcome in its role, read its sources rather than its summaries, keep its working state to one page of current truth, and turn each recurring problem into a check, a clearer finish line or a named method. Keeping a resident agent on course sets out the rules. Autonomy is extended a step at a time, each step with a stated reason to advance, and sometimes the right change is a narrower job.

The client approves any change to the agent's role or authority, and any step up in what it may do alone.

It leaves review notes and a dated record of changes.

What the client controls

The client owns three things throughout: the role, the authority table, and the decision to go on at each gate. The agent never widens its own authority; a change to it is a decision the client makes and we record. Any gate can end the work, with a written account of why, and everything produced up to that point stays with the client.