How AI agents work inside business software.
An agent takes a defined job, gathers the context it is allowed to see, works through several steps with approved tools and prepares a result. The software around it — records, permissions, approvals and audit — is what makes it safe to use.
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.
See this job in full: who has paid, who has not and who paid the wrong amount
The agent gathers the right information and prepares the work. A person stays in control of important communication.
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.
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.
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.
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.
| Customer | Relationship | Record |
|---|---|---|
| Customer | belongs to | Company |
| Customer | owes | Invoices |
| Customer | discussed in | Emails |
| Customer | attended | Bookings |
| Customer | raised | Support cases |
| Customer | owns | Tasks |
| Customer | affected by | Previous agent actions |
Instead of searching unrelated records one by one, the software can follow the connections that matter to the job.
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.
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.
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.
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.
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.