Reference Architecture for a Business AI Agent

A business AI agent needs more than a model and a tool list. It needs a defined task owner, permitted evidence, bounded actions, durable state and a way to prove what happened. The model can propose the next step; the application enforces permissions and executes it. This article presents AGENT-REF-8, an original reference design for one bounded workflow. It is a synthetic design example, not a client deployment or performance claim.

For broad partner selection in Armenia, see the AI specialist page. Here the question is narrower: how should the runtime around a model be structured?

The business problem and requirements

Consider an incoming B2B request. An agent finds the current customer record and contract terms, drafts a CRM update and prepares a reply. Reading a record, changing it and sending a message are three separate permissions. The owner defines the accepted outcome, allowed systems, data classes, action limits, review owner and failure route before giving the agent a tool.

A deterministic workflow is often enough when every route is known. A retrieval assistant may be enough when the outcome is an answer. Use a bounded agent when the next step depends on context and must be chosen within an explicit contract. The agent versus chatbot comparison gives a task-level decision framework.

Solution architecture: AGENT-REF-8

The eight nodes can be modules in one application or separate services. Their contracts matter more than the deployment count.

There are three trust boundaries. First, user text and retrieved documents are data, never a source of application authority. Second, a model plan is a proposal: the gateway validates every call against the policy and current target version. Third, an API success response is not always a confirmed business effect. The receipt layer checks the destination and keeps unknown outcomes for reconciliation.

The tool calling guide, planning guide and state and memory guide expand those nodes.

Component contracts and pseudocode

Each step carries taskId, tenantId, actorId, policyVersion, sourceVersion and traceId. Its terminal route is one of verified, hold, deny, clarify and reconcile. Keep sensitive payloads out of ordinary telemetry; store a protected reference and a bounded reason code instead.

async function route(action: ProposedAction, actor: Actor) {
  if (!policy.allows(actor, action.tenantId, action.tool, action.targetId)) return "deny";
  const current = await destination.readVersion(action.targetId);
  if (current.version !== action.expectedVersion) return "hold";
  if (policy.requiresReview(action)) {
    const approval = await approvals.findExact(action.payloadDigest, action.targetId);
    if (!approval?.validNow()) return "hold";
  }
  const result = await gateway.executeOnce(action, action.idempotencyKey);
  if (result.effectUnknown) return "reconcile";
  return destination.verifyEffect(result) ? "verified" : "reconcile";
}

This is a control-order sketch, not a production library. A real implementation also needs transactional checkpoint writes, adapter authentication, secret management and recovery from partial execution. The human approval guide explains exact-action review.

Failure modes

Instructions inside retrieved text. A document may tell the model to send data elsewhere. Treat it as quoted evidence; never grant new tool rights because it says so.

Stale target state. A colleague changes the CRM record while a draft is prepared. Compare versions before the write and hold the action for a fresh diff.

Timeout after an effect. The integration may have written successfully while the response was lost. Reconcile by idempotency key or destination read-back before retrying.

Lost conversational context. A restarted worker must load a versioned checkpoint and receipts, then recheck rights and source freshness. Chat history alone cannot authorize a resumed action.

Implicit permission expansion. “Help with sales” does not grant permission to email a customer or change a price. Policy binds target, action type and impact.

Tests and production path

Build synthetic fixtures for a normal request, incomplete input, cross-tenant access, a removed document, stale CRM state, injected instructions, integration failure and timeout after a successful write. For each fixture, assert the terminal route and absence of forbidden effects. Test concurrent workers and reuse of an approval for a changed payload.

Start with read-only evidence and draft generation. Add one narrow write path with human review, receipts and rollback. Before expanding it, check retention, access, incident ownership, observability and call costs. Measure hold and deny rates, source failures, review time and unknown effects in your own pilot; no benchmark is claimed here.

Prompt engineering supports answer format and evaluation. AI automation connects the route to the business process. For an architecture review, share the process: input, permitted action, system owner and one difficult failure case.