Technology
Agentic AI Architecture
An agent is a bounded role with context, tools, rules and a verifier. Here is how they are built and governed.
The concept
The agentic AI architecture in one loop
An agentic AI architecture is a loop, run by a bounded role, inside a workflow an orchestrator controls. This page is the architecture review, for the person who has to approve it.
An agent in the PTAS AI architecture is a role with four parts. It is given a context: the document or record in front of it, plus the policy, master data and history that bear on it. It has tools, each one a declared action it may take. It has rules it must apply before it decides. And it has a verifier, which checks that what it did was within the rules and that the system on the other end agrees. With those parts it runs one loop, observe, reason, decide, act, verify, then writes all five steps to the item's record and stops.
No agent does everything. The Invoice Agent reads and has no tool that posts. The Posting Agent posts and never reads the invoice; it works from what earlier agents established. A narrow job is what makes an agent testable and replaceable, and it keeps a failure inside one step. Between the agents sits an orchestrator, which holds the item's state, picks which agent runs next, retries a failed step and escalates what no agent is allowed to settle. The model inside an agent proposes, the rules decide whether the proposal stands, and the orchestrator moves the work.
That is also why this is not a chatbot. A chatbot with system access has a prompt and whatever permissions it was handed, and its boundary is the model's judgement on the day. Here the boundary is configuration: which tools an agent has, which systems each may touch, which rules it reads, and above which value a person must look. Each of those is written down and versioned. The model can be swapped out; the boundary stays. It is slower to build than a prompt with database access, and that is deliberate.
Where it sits
Where an agent sits in the five stages
Every PTAS AI workflow runs through Perception, Intelligence, Orchestration, Action and Verification. An agent reasons in the second stage. The other four decide what it is given, what it may touch and whether it was right.
In the products
How agents are built inside DocPro and FinSuite
DocPro agents are built to read and score. FinSuite agents are built to check and act. Same AI agent architecture, different tools and permissions. The Agentic AI Platform page shows the controls as you would configure them.
DocPro
One agent per document type
The Invoice, Receipt and Bank Statement Agents are separate agents with their own schema, validation rules and thresholds. A change to one cannot break another.
DocPro
Tools that read, never post
A document agent's tools are narrow: read the typed fields, resolve a name against the vendor or item master, score each field. It has no posting tool to misuse.
DocPro
A verifier made of checks
Arithmetic, tax and schema checks run on every extraction before confidence is considered. A field that fails goes to review with the failed check named. Custom document agents are governed the same way.
FinSuite
State arrives, documents do not
The Matching Agent receives what the Invoice Agent established (lines, tax, vendor) as state and adds the purchase order and GRN it found. It does not re-read the invoice.
FinSuite
Rules read at run time
Approval bands, tolerances and the exception policy are configuration the agent reads when it runs, versioned per entity. An agent cannot widen its own band.
FinSuite
Posting as a permission
Writing to the ERP is a tool with its own permission, held by the agents whose job is to post, through the integration method agreed during assessment. The step is done when the document number comes back.
Worked example
A multi-agent workflow, then one decision from it
One supplier invoice through five agents, then one decision on it opened up. The first figure is the orchestrator's view of the item. The second is an auditor's view of a single step.
One invoice, five agents, no handover meeting · Illustrative example
Narrow jobs are deliberate. An agent that does one thing can be tested, measured and replaced; one that does everything cannot.
One job each
The Invoice Agent cannot post. The Posting Agent never reads the invoice. A failure stays inside one step.
State travels with the item
Each agent adds to one record, and the next starts from that record rather than from the document.
The orchestrator moves it
Which agent runs next, when to retry and when to stop for a person are its decisions, not any agent's.
Now open one decision on that invoice. The record holds the values the agent saw, each rule it applied with its result, the band that sent it to a manager, and the posting the ERP confirmed. The values are illustrative. Anyone with the right role can query this months later, and nobody has to reconstruct it.
One decision, kept in full · Illustrative example
This is what separates an agent from an automation: it can tell you why, months later, without anyone reconstructing it.
What it saw
The document, vendor and value as the agent read them at the time.
Which rules it applied
Each rule with its result, and the band that sent the invoice to a manager.
What it did, then checked
The approval, the posting, and the ERP's own document number read back.
Limits and controls
What an agent cannot do on its own
An agent reasons about what it is given. It cannot apply a policy nobody wrote down, or tell that the approval matrix it was handed went out of date last quarter. A model can be fluent and wrong at the same time, and a loop without a verifier will act on the fluency. Two agents holding the same tool, with no orchestrator between them, will both act. An agent that carries its own memory from case to case cannot be audited, because what it knew depends on what it processed earlier. A better model does not close those gaps. The structure around it does.
Declared tools and permissions
An agent can call only the tools declared for it, and each tool has its own scope: read a master, write to the ERP, send a notification. Adding a tool and watching an agent run are separate roles.
State on the record, not in the agent
An agent keeps no memory between cases. It knows the item's record and what it retrieves from your systems at run time, so what it knew when it decided is what was written down.
Rules as code, versioned
Thresholds, bands, tolerances and routing are configuration with a version, an author and an effective date, rather than text inside a prompt. The agent reads them and cannot change them.
Failure handled by the orchestrator
A step that times out is retried. A tool error is retried after a pause, then the item is parked with the reason. A posting the ERP did not confirm is never marked done, and a retry cannot post twice.
The review queues these controls feed are described under Human-in-the-Loop, and the permissions and audit logs under AI Security and Governance.
FAQ
Questions Teams Ask
Is an agent here a language model with access to our systems?
No. The model is one component inside the agent, used to read, normalise and classify. Around it sit a declared context, declared tools, the rules it must apply and a verifier. The model proposes a next step, the rules decide whether the proposal stands, and the verifier confirms what happened. A model with a prompt and direct system access is a chatbot with privileges, and the architecture has no place to put one.
How do agents share what they know if none of them keeps a memory?
Through the item's record. The Invoice Agent writes what it extracted, the orchestrator hands the record to the Matching Agent, which adds the purchase order and goods receipt it found, and so on down the chain. Anything beyond the record, such as a prior invoice from the same vendor, an agent retrieves from your systems or the knowledge base when it runs. Nothing is held privately, so a reviewer sees the exact state each agent worked from.
What happens when an agent fails part way through?
The orchestrator handles it. A step that times out is retried. A tool that keeps returning an error gets the item parked, with the reason, in a queue a person owns. If the agent acted but the verifier could not confirm the result, say a posting the ERP never acknowledged, the item is held as an exception rather than marked done, and a retry cannot post twice. The queue shows the item, the step it stopped at and why.
Can we change what an agent may decide on its own without a software release?
Yes, within limits. Authority is configuration: the confidence threshold, the value band, and the document types and counterparties that always need a person. An administrator with the right role changes those, the change carries an author, an approver and an effective date, and the previous version stays for the audit trail. Giving an agent a new tool, integration or document type is engineering work and goes through a release, because it changes what the agent can reach rather than what it may decide.
Keep reading
Related Capabilities
Agentic AI Platform
The product view of this architecture: what you get, and the controls as you would configure them.
Read more →Autonomous AI Agents
The roster of named agents in three teams, and the narrow job each one owns.
Read more →AI Orchestration
The orchestrator in detail: handoffs, state, retries and escalation across several agents.
Read more →Business Rules
The rules an agent reads at run time, kept explicit so they can be read and changed.
Read more →Next step
Bound the first agent before it is built
Bring one workflow. We will write down what the agent may decide alone, which tools it needs, which rules it reads and where a person stays in the loop, then build it to that.