Agentic engineering

Agentic engineering, as AR Labs uses the term, is building software with and around AI agents (language models run in a loop with tools, so they can act, not only reply) by designing the harness, context, tools, gates, verification and cost. Prompting asks how to word a request. Agentic engineering asks what the agent can see, what it can touch, what checks its work, who decides at each point, and what each step costs. The model is one component; most of the engineering is in the system around it.

The problem it answers

An agent does things: it edits files, calls services and takes actions with consequences. It is also probabilistic. The same request can succeed once and fail the next time, and a failure often arrives as a confident, well-written wrong answer rather than an error. A system built on a better prompt alone has no way to notice. In our experience, output quality is capped by the quality of the feedback loops around the agent: an agent whose only signal is "it compiles" produces code that compiles.

The loop

flowchart LR
  I["Intent: goal and acceptance criteria"] --> C["Context: what the agent sees"]
  C --> A["Agent acts through tools"]
  A --> S["Sensors: tests, floors, review"]
  S -->|"fails"| C
  S -->|"passes"| R["Record: durable state"]
  R --> G{"Human gate?"}
  G -->|"holds"| P["Person decides"]
  G -->|"relaxed"| N["Next step"]
  P --> N

Birgitta Böckeler's article on harness engineering, published on Martin Fowler's site, gives a useful split for the parts of this loop. Guides are feedforward controls that steer the agent before it acts: instructions, specs, design records, tool schemas. Sensors are feedback controls that observe after it acts and let it correct: tests, type checks, scripted proofs, independent review. Guides without sensors produce unchecked work. Sensors without guides check work that may be aimed at the wrong target.

Six things the engineer designs

1. The harness. Everything around the model that shapes what an agent does: the agent program, its instructions, skills, hooks, tools and checks. In practice that means standing instructions, skills loaded on demand, hooks that run before actions, subagents, memory and tools. See agent harness anatomy for each part, and harness engineering for turning recurring mistakes into enforced checks.

2. Context. What enters the context window at each step, and what stays out. We load the most constraining information first and detail on demand, keeps each fact in one place, and writes any decision that must outlive the session to a file or the task tracker. Conversation history is a convenience, not a store: anything that would break if it were summarised into one sentence has to live outside it. See context engineering.

3. Tools and their contracts. A model knows a tool only through its schema, and it will produce something that matches the schema's surface form even when the meaning is wrong. Strict types, enumerations, required fields and descriptions written as instructions prevent a whole class of failures before any prompt is touched.

4. Gates. Where a person must decide, and how cheaply. We keep people at the design, the plan and the merge, and lets an autonomy level decide which other gates an agent may pass. See human-in-the-loop gates.

5. Verification. Proof that does not depend on the agent's say-so: tests written before the code, a manifest of evidence for each criterion, scripts that check git and the filesystem, and review by a different vendor's model in a fresh context. See evidence of completion and the code review gate.

6. Economics. Which model and effort level each step gets, when to delegate at all, and how many agents to run. See model routing and agent economics.

When the agent is the product

Some of our systems contain an agent as a component, such as a voice agent that runs a sales conversation. For those, we work through a checklist of seven concerns for agents that people rely on, adapted from a public video on the skills needed to build AI agents, each with a typical failure:

Concern	The question	What fails without it
System design	Is the architecture drawn, with failure paths?	Works in a demo, collapses in use
Tool contracts	Are schemas strict, with examples?	Invented IDs and wrong types
Context and retrieval	Is critical state kept outside the conversation?	Decisions lost when history is summarised
Reliability	Timeouts, retries with backoff, fallbacks, loop caps?	One slow dependency stalls everything
Security	Least privilege, destructive tools gated, retrieved text treated as data?	Prompt injection turns the agent against its owner
Evaluation	Traces and a frozen test set run after every change?	"It seems better" becomes the release criterion
Product	Does it signal uncertainty, fail helpfully and hand off to a person?	Users leave after one bad answer

A worked example: debugging by trace

Illustrative example. An agent that looks up customer orders starts returning the wrong customer's data. The tempting fix is to reword the prompt. Our practice is to trace backward through the system instead:

1. Was the right information retrieved?
2. Was the right tool chosen?
3. Was the tool's schema clear enough to produce a valid input?
4. Did the tool succeed?
5. Did the model reason correctly over the result?

The trace shows step 3 failing. The tool declared customer_id as a bare string, and the model, unable to find an ID, passed the customer's first name. The lookup matched a different customer with the same name and returned that record, which the model then reported with full confidence. The fix is in the contract, not the prompt: the schema now gives the ID's pattern and an example, the tool rejects any value that does not match, and a test covers the rejection. Our debugging procedure starts from the assumption that the cause usually sits somewhere in the system rather than in the prompt's wording, and checks the system first.

What exists today

We apply this discipline to our own development through the coding pipeline, which runs attended and unattended, and to the agents we build, such as the Salesbot. The harness paradox sets out our view of why tighter constraints let agents do more useful work on their own.