Engineering AI within a software system

Choose the execution pattern around the work

A business application can use fixed rules, model tasks, AI workflows and agents in the same process. The choice concerns how each part of the work is performed and checked.

Application code is well suited to rules the business can specify: a required field, a calculation, an account permission or a permitted change to a record. A model adds the ability to interpret less structured information, retrieve relevant material or prepare a response.

A defined workflow sets the stages in code. An agent lets a model select its next permitted tool or step as it works toward an objective. That flexibility is useful when the information found along the way determines what to inspect or do next.

Consider a service request. Software can establish the user’s access and record the request. A model can interpret its contents. An agent can consult approved sources, investigate missing information and prepare an action. The application then applies the relevant validation and approval policy before a business record changes.

Anthropic’s architectural guidance distinguishes code-defined workflows from agents that direct their own process and tool use. The distinction helps describe a scope precisely; a product does not need to choose one pattern for every task. Building effective agents

Design the operating boundaries with the capability

An agent’s instructions describe its task. The surrounding application enforces what the system can actually do. This includes the records available to it, the tools it can call and the changes those tools permit.

For an agent handling a request, that may mean reading an authorised set of records, asking for missing details and preparing a proposed update. The client decides which actions may run automatically and which require approval. We implement that policy in the application, including who can change it. The design should make the permissions and current approval requirements visible to the responsible people.

Data access

Which records and reference material can this user and this run use?

Allowed actions

Which tools are available, with what inputs and permission checks?

State and validation

What has happened, what remains unresolved and what must be checked before a change?

Review and recovery

When should a person decide, when should work stop and how can an interrupted process continue?

Structured output helps an application parse a result. It does not establish that every plausible field matches its source. Evaluation and business validation still need to examine meaning, including what the system does when it cannot establish an answer.

Evaluate capability and repeatability

Agents can make a system more capable when it needs to adapt its next step, investigate through tools or coordinate independent work. Additional computation can be justified by a better result.

That finding supports an application-specific question: does the added capability improve the work enough to justify its operating demands? The answer requires representative tasks and agreed review criteria, including the actions taken along the way.

Repeatability deserves its own test. A successful demonstration shows that a task can be completed once. An operating service also needs an understanding of how consistently the implementation handles the work.

The implication is to evaluate several complete runs, inspect failures and test the exception route. These research results do not establish a failure rate for your organisation. They illustrate why one successful example is insufficient evidence for release.

The interface available to an agent also matters. In the April 2026 AutomationBench paper, reported scores changed when the same models received different tool interfaces. A limited mode supplied task-relevant tools in advance, removing some discovery work. That is useful evidence about interface design, with a privileged narrowing of the task; it is not a measured saving from replacing agents with automation. AutomationBench v1, section 7

Compare the model usage before scaling

A running-cost estimate needs the expected volume, the calls each item triggers, the information sent with each call and the allowance for retries. An agent may vary its steps from one case to another; a defined workflow makes some of that structure explicit.

The calculator below lets you compare two token budgets. It does not assume the designs produce the same quality. That is a separate question for the evaluation.

For a real implementation, use observed distributions as well as averages. Long documents, repeated context and difficult cases can consume more than an ordinary item. Review the costs of accepted results and the work left for people.

Measure the complete process

The objective is a useful operating service. Model quality, application correctness, integration behaviour and human effort all contribute to that result.

• Quality: useful outputs, accepted results, corrections and errors reaching another system.
• People: review time, unresolved cases and effort spent recovering an incomplete run.
• Operation: completion time, permissions, failures, repeat actions and recovery.
• Cost: model usage, tool charges, hosting, monitoring, support and maintenance.

Agree the intended use and acceptance criteria before the build. Give the implementation representative examples, including missing information and unusual requests. Compare the relevant alternatives using the same tasks, and record the conditions under which each performs well.

We develop AI and agents as part of that software system: the capability, its tools and interfaces, its evaluation and the controls needed to operate it. The appropriate design follows the work and the evidence from testing it.