AI agents
The agent is the runtime inside an intelligent application.
It interprets a responsibility, assembles relevant context, works through multiple steps and uses approved capabilities. The lasting product is the application around it: state, permissions, evidence and a useful interface.
A real job
Who has not paid this month?
A useful explanation starts with the work, not with a model name or an architecture diagram.
- Checks the agreed customer and account scope.
- Reads current invoice and payment state.
- Identifies overdue accounts using explicit business rules.
- Looks at previous communication and relevant promises.
- Produces a reviewable list with the reason each account appears.
- Prepares an appropriate follow-up where permitted.
- Requests approval before external communication when required.
- Records the approved action in the CRM.
The agent gathers the right information and prepares the work. A person stays in control of important communication.
What it is not
An agent is not a promise of unrestricted autonomy.
Some systems should answer a question. Some should draft work. Some may take a low-risk action. Those are different products with different controls.
Primarily exchanges messages. It may have knowledge but often has no operational authority.
Runs a predictable rule or workflow where inputs and transitions are known.
Helps a person understand information or prepare a decision.
Coordinates context and tools to complete a bounded multi-step job.
Modular runtime
Keep models and capabilities replaceable.
Models change quickly. Business responsibilities, data boundaries and permission rules need a more stable home inside the application.
Select local, private-cloud or external intelligence according to the task, sensitivity, capability and cost.
Expose narrow reads and actions through typed plugins rather than giving an agent unrestricted system access.
Assemble approved state, knowledge, memory and live results independently from the model prompt.
Measure context quality, decisions, tool use and workflow outcomes so one component can change without hidden regressions.
Context engineering
How does the software know what is actually happening?
A model alone does not know the customer, current task, previous interaction, permission or state of the business. The system has to assemble that information deliberately.
Customer
Who the work is about.
Situation
What is happening now.
Rules
What the business allows.
Context graphs
Understand how information is connected.
A customer record gains meaning from its relationships to the company, invoices, emails, bookings, support cases, tasks and previous actions.
├── belongs to → COMPANY
├── owes → INVOICES
├── discussed in → EMAILS
├── attended → BOOKINGS
├── raised → SUPPORT CASES
├── owns → TASKS
└── affected by → PREVIOUS AGENT ACTIONS
Instead of searching unrelated records one by one, the software can follow the connections that matter to the job.
Memory
Remember what matters, not everything.
Memory should improve a future decision. Keeping every message forever creates privacy, relevance and cost problems without guaranteeing better work.
Conversation memory
What has already been established in the current exchange.
Business state
Durable facts such as status, ownership, permissions and commitments.
Episodic memory
Important events that may change how a similar future task is handled.
Observational memory
Selected summaries of patterns that remain useful over time.
Semantic recall
Finding relevant knowledge by meaning rather than exact wording.
Structured memory
Explicit fields and relationships that remain inspectable and correctable.
Tools
A chatbot can tell you. A controlled agent can help do it.
Tools connect the reasoning layer to the business systems where information and work already live.
- Each tool exposes only the operation the job requires.
- Identity and permission travel with the request.
- Reads and writes are distinguishable and observable.
- Retries cannot repeat a payment, email or irreversible change.
- Important actions pause for a person or policy decision.
Human control
Make authority visible.
The system should make it clear what the agent can see, what it can change, who approved the action and how the result can be reviewed.
Identity
Know which person, service or agent initiated the work.
Permissions
Limit access by role, task, customer and environment.
Approval
Pause before sensitive communication, spending or state change.
Audit
Record inputs, tool calls, decisions, approvals and outcomes.
Evaluation
Measure grounding, task quality, policy adherence and workflow impact.
Rollback
Design reversible or compensating actions before something goes wrong.
Single or multiple agents
Add another agent only when specialisation creates a real boundary.
A multi-agent diagram can look impressive while making a system slower, harder to evaluate and more expensive.
One agent with clear tools is often the best first implementation. Separate agents become useful when jobs require different permissions, context, evaluation, ownership or timing.
The task shares one context, one policy boundary and one measurable outcome.
Finance, support or sales work needs distinct identity, tools or approval policy.
Agents share structured work state rather than relying on uncontrolled conversation.
Latency, cost, hand-offs and failure recovery need end-to-end evaluation.
A useful first step
Start with one useful workflow.
We will help define the job, the context it needs, the tools it may use and the evidence that would prove it works before expanding the system.