An AI agent is useful only when it is connected to a clear business workflow. The model can reason, but the system around it decides which tools it can use, what context it can read, when it must ask a person and how every action is recorded.
The agent loop
- Goal: the user or workflow gives the agent a bounded task.
- Context: the agent receives documents, records, policies and current state.
- Plan: the agent chooses a next step and the tool it needs.
- Act: the system executes a safe tool call or prepares a human approval request.
- Observe: the result is logged and fed back into the next step.
A practical architecture
| Layer | What it does | Why it matters |
|---|---|---|
| Interface | Captures the request and shows state | Keeps the workflow understandable |
| Orchestrator | Runs the agent loop and tool calls | Prevents the model from becoming the whole system |
| Knowledge | Provides documents, policies and records | Grounds answers in approved sources |
| Approval | Routes risky steps to people | Keeps accountability visible |
| Audit | Stores prompts, actions and outcomes | Supports debugging, security and governance |
Safe tools beat unlimited autonomy
The strongest agent systems use boring, reliable controls: scoped permissions, deterministic tools, retries, rate limits, audit logs and clear escalation. The model should not have direct access to everything.
type AgentTool = {
name: string
permission: 'read' | 'draft' | 'approve-required'
handler: (input: unknown) => Promise<unknown>
}
const tools: AgentTool[] = [
{ name: 'searchKnowledge', permission: 'read', handler: searchKnowledge },
{ name: 'draftApproval', permission: 'draft', handler: draftApproval },
{ name: 'sendToClient', permission: 'approve-required', handler: sendToClient },
]The real product is not the model. The product is the workflow around the model.
Krishnam Murarka
Data contracts make the agent dependable
A production agent should not read every system casually. It should receive a small contract: allowed sources, fields it can use, records it can update, and the approval rule for every action. This makes the workflow easier to review, test and support.
| Risk | Control | Operational signal |
|---|---|---|
| Wrong context | Approved retrieval sources and freshness checks | Source names and timestamps appear in the audit trail |
| Unsafe action | Tool permissions and approval gates | Every write action has an owner and status |
| Silent failure | Human fallback and queue state | Failed actions create visible tasks |
| Unclear output | Templates and structured response schemas | Downstream systems receive predictable fields |
A practical launch plan
- Start with a workflow that already has a clear owner and repeated decision pattern.
- Measure the manual baseline before automation so the improvement is visible.
- Launch in draft mode first, where the agent prepares work but people approve the final action.
- Record every tool call, retrieved source, edited field and approval decision.
- Move one action at a time from draft to controlled execution.