Skip to content
Talk to QCS
Home / Agentic Automation / AI Architecture

For technology teams · The reference behind the five Agentic Automation workflows

Rules, records and agents. How it holds.

Twelve responsibilities in five bands. The ERP owns the transactions, agents work within a defined scope, people own policy and exceptions, and identity, the action gate and audit apply across the design.

A practical reference architecture for operations, finance and technology leaders. Start with one workflow. Measure the result. Expand what works.

The operating loopReference design
AI proposes. Policy checks. The business system executes. An agent reads authorised business context and proposes an action. A code-enforced gate checks policy and routes exceptions to a person. Approved actions pass business validation before execution. A trace links the whole loop. 01 · INTELLIGENCEAgent proposes 02 · CONTROLPolicy checks 03 · BUSINESS SYSTEMValidate & act Personowns exceptions authorised context ONE TRACE · REQUEST → DECISION → OUTCOME
AI proposes. Your rules govern. Every action has an owner.
01 · The architecture

A business system with AI inside. Accountability throughout.

The ERP owns the transactions. Agents work within a defined scope. People own policy and exceptions. Identity, action controls and audit apply across the design.

QCS reference architectureSelect a layer to explore ↓
Twelve responsibilities, five bands. The gate protects ERP writes and external actions such as sending a message or issuing a payment. The bands group responsibilities.
Twelve responsibilities do not mean twelve products.

Several can live in one platform. This is a reference design: retrieval controls, action gates and end-to-end tracing need implementation and testing for each deployment.

Explore each responsibility

E · GovernanceWho owns the outcome
12Oversight & operating modelAn owner, an operating limit and a stop control for every agent.

Name the business owner, permitted actions, approval thresholds and escalation path. Review incidents and retire agents that do not earn their operating cost.

Design rule. No autonomous workflow without a named owner and a way to stop new actions.

Reference implementation. An agent register, a decision-rights matrix and an incident playbook. Keep enforceable limits in versioned policy, alongside the approved business policy.

11Observability, evaluation & auditConnect the request, decision, approval and recorded outcome.

Link model and tool calls, source references, approvals and business changes with a run ID. Track task success, rework, latency and cost per completed outcome. Redact sensitive content and define access and retention.

Design rule. Test model, prompt, retrieval and tool changes against representative cases before release. Investigate production exceptions.

Reference implementation. OpenTelemetry traces, a case-based evaluation set and ERP audit records. Export audit evidence to protected storage when the retention requirement calls for it.

D · SurfacesWhere work arrives and decisions get made
10ChannelsWhatsApp, email, portals, voice and partner APIs.

Attach incoming requests and outgoing messages to the relevant business record. Verify the sender and permitted account scope before disclosing order, employee or payment information.

Design rule. A message is a request, not proof of identity or authority. Outbound actions pass policy checks too.

Reference implementation. Frappe communication and CRM, channel adapters and customer or supplier portals.

09Human workspaceA clear work queue for the decisions people must own.

Present the proposed action, source evidence, applicable rule and expected business effect. Let the reviewer approve, amend or reject, with the decision recorded.

Design rule. Approval applies to a specific action and record version. Material changes require review again.

Reference implementation. Frappe Desk, ERPNext approval workflows and a tailored exception queue where needed.

C · IntelligenceReasoning inside a bounded workflow
08Agents & workflowsRead authorised context. Propose an action. Wait for permission.

Give each agent a narrow task and allowlisted tools. Persist workflow state across waits and restarts. Separate model reasoning from code that checks policy and executes actions.

Design rule. Retries can happen. The receiving service must recognise the same operation and prevent duplicate effects.

Reference implementation. A Python worker to start; LangGraph with persistent checkpoints for multi-step agent state. Consider Temporal when long-running recovery across services becomes necessary.

07Models & gatewayApproved model routes, data boundaries and budgets.

Choose hosted or private models against your data policy and a task-specific evaluation set. Route calls through a gateway with model allowlists, usage limits and controlled logging.

Design rule. A fallback must remain within the same data boundary. A gateway does not make an unapproved provider acceptable.

Reference implementation. A gateway such as LiteLLM; hosted models or private inference chosen through a measured pilot. Private hosting still needs access, retention and network controls.

B · Business coreThe records and context decisions depend on
06Analytics & shared metric definitionsThe same business meaning for a dashboard and an agent.

Assign owners to revenue, margin and service metrics. Publish versioned definitions, dates and dimensions, then expose approved reports or query endpoints to people and agents.

Design rule. Financial amounts come from validated records and business calculations. The model does not invent them.

Reference implementation. Frappe Insights and governed reports first. A shared semantic service and warehouse are options when multiple systems or reporting loads justify them.

05Knowledge & contextRelevant evidence, retrieved within the caller’s permissions.

Index approved policies, procedures, contracts and decisions with an owner, effective date and access rules. Return source references. Treat retrieved text and attachments as untrusted input.

Design rule. Filter access before context reaches the model. Retrieved instructions cannot grant new tool permissions.

Reference implementation. Frappe Wiki, document storage and the Decision Ledger, with an explicitly implemented retrieval and permission layer. Add a dedicated search index only when needed.

04Integration & event backboneReliable connections to systems with clear boundaries.

Use APIs, adapters and background jobs. For important events, persist delivery intent with the business transaction, then handle retries, timeouts, failed deliveries and reconciliation.

Design rule. Expect repeated delivery. Use stable operation IDs and deduplicate at the destination; a webhook alone is not a delivery guarantee.

Reference implementation. Frappe APIs and jobs, plus n8n for connector workflows. MCP is an optional tool interface, not an authorisation or reliability layer. Add a broker only for demonstrated fan-out or throughput needs.

03System of recordAuthoritative master data, transactions and business validation.

Keep an authoritative owner for each business domain: customers, items, employees, orders, stock and finance. Enforce business rules in supported application APIs and give data stewards responsibility for quality.

Design rule. Agent integrations use scoped APIs. No direct database writes, permission bypasses or model-invented financial values.

Reference implementation. ERPNext and Frappe on MariaDB as the reference baseline, extended with domain applications. Existing systems can remain authoritative where migration has no clear benefit.

A · FoundationIdentity, infrastructure and recoverability
02Identity & accessA verifiable identity for every person, service and agent.

Use your identity provider for people and scoped workload credentials for agents. Preserve the initiating user and permitted scope across requests. Manage credentials outside prompts and rotate them.

Design rule. Recheck identity, scope and authority at execution. SSO alone does not grant business permission.

Reference implementation. Your existing identity provider, Frappe roles and scoped service accounts. Keycloak is an option when a separate identity service is needed.

01Infrastructure & recoveryChoose where data runs and prove you can restore it.

Define data residency, backup ownership, monitoring, patching and recovery objectives. Test restores and document how staff continue critical work while AI services are unavailable.

Design rule. Agree acceptable data loss and recovery time, then test them. Availability targets require an operational design.

Reference implementation. Containers or managed hosting, MariaDB and Redis for the ERP baseline, encrypted backups and a tested recovery runbook. Add replicas and redundant services against agreed recovery targets.

02 · The design rules

Tools change. These boundaries should hold.

Every action crosses a boundary the model cannot override. Check the caller, the business rule and the required approval.

An action needs all three checks
  1. Identity & scopeMay this agent act for this customer?
  2. Business policyAre the action and amount within its limits?
  3. ApprovalIs the required decision recorded?

All passValidate & execute

Any failHold or reject

Code enforces these checks. The model cannot grant itself permission.
01 · Authority

The record has the final say.

Use the authoritative system's validation for every change. Give each data domain an owner.

02 · Access

Read only what the task needs.

Filter documents, records and tools by the caller's scope. Recheck permission when an action executes.

03 · Control

Enforce policy in code.

Prompts guide behaviour. The action gate enforces limits, approvals and permitted destinations.

04 · Accountability

Every exception has an owner.

Show a person the proposal, evidence and business effect. Record the decision and its scope.

05 · Evidence

Measure completed work.

Track correct outcomes, human effort, rework and operating cost. Keep trace data proportionate and protected.

06 · Recovery

Design for failure and retries.

Prevent duplicate effects. Test recovery, reconcile uncertain outcomes and keep a manual route available.

03 · A practical stack

Start with the core. Earn every extra component.

Our recommended starting point for a Frappe-centred business. These are implementation choices, not a claim that every capability is already built into the products.

Reference choices · adapt to your existing systems, data policy and operating team
ResponsibilityStart withWhat makes it work
Business recordsERPNext + Frappe
MariaDB · Redis
Owned master data, validated application APIs and tested backups. Keep existing authoritative systems where useful. [1]
IdentityYour existing identity provider
Frappe roles · scoped agent accounts
Carry the initiating user and scope to execution. Add Keycloak if you need a separate identity provider. [2]
Action gateA small application service
Python · explicit policy · approval records
Check permissions, limits, record version and operation ID before a supported API call. Keep secrets and direct database access out of agent tools.
IntegrationFrappe jobs + APIs
n8n for connector workflows
Persist important work, handle retries and reconcile results. Connector execution does not replace ERP validation. [3]
Agent executionA bounded Python worker
LangGraph when multi-step state is needed
Allowlist tools, persist state and pause for approvals. Use a persistent checkpointer when choosing LangGraph. [4]
Model accessA gateway such as LiteLLM
Approved hosted or private models
Set model routes, budgets and logging policy. Evaluate providers on your own cases before enabling fallback. [5]
Knowledge & metricsFrappe Wiki + governed reports
Insights · permission-filtered retrieval
Implement document access filtering explicitly. Share metric definitions between reports and agent tools; source monetary values from records. [6]
EvidenceOpenTelemetry + ERP audit
Representative evaluation cases
Correlate requests across services. Redact sensitive data, control access and retain business evidence to the agreed policy. [7]
Add when · workflows span outages

Durable orchestration

Consider Temporal for long waits, recovery and coordination across services. Keep duplicate prevention in the receiving business service. [8]

Add when · data outgrows the core

Dedicated data services

Introduce a warehouse, shared semantic service or search index when volume, multiple sources or retrieval quality justify the operating cost.

Add when · recovery targets require it

More infrastructure

Choose replicas, a broker or a cluster against measured load and recovery objectives. A pilot needs a proven restore path from day one.

How a pilot runs

One process. A defined pilot and a release decision.

Bring a process owner, representative cases and the systems involved. Together we find the data gaps, the approval requirements and what a useful result looks like.

  1. 01 · Scope

    Agree the boundaries

    Define the workflow, permitted actions and customer inputs. Agree an estimate and the ongoing operating responsibilities.

    Output: a pilot scope, baseline and success measures.
  2. 02 · Test

    Start with drafts

    Test representative and difficult cases: missing data, hostile attachments, duplicate requests and failed steps.

    Output: a traced pilot and evaluation results.
  3. 03 · Decide

    Review the evidence

    Compare the result with the baseline. Agree what can proceed, what stays under review and who operates it.

    Output: a rollout, revision or stop decision.
Authority grows only as the evidence supports it
  1. StartDraft only

    The agent prepares.
    A person executes.

    Check quality against real cases.
  2. ThenApproved actions

    A person reviews.
    The workflow executes.

    Prove approvals, retries and recovery.
  3. When justifiedBounded autonomy

    Low-risk actions proceed.
    Exceptions go to the owner.

    Monitor quality, effort and cost.
Each increase in authority is a release decision. Some workflows should stay approval-based.
Agreed before the pilotCorrect completionHuman minutes per caseRework rateCost per outcomeRecovery from failure
Will we have to replace our ERP?

We assess the existing systems first. Integration is often enough; a migration needs a clear business reason of its own.

What does a pilot cost, and how long does it take?

It depends on the process, data quality, integrations and required controls. Scope, estimate, timing and responsibilities are agreed in writing before implementation.

Is our process ready for a pilot?

Start with a named owner, representative cases, the required fields, the business rules and the approval roles. If those foundations are missing, we define them first; automating an undefined process does not fix it.

Technical references & design notes

This is QCS's recommended reference design. The documentation below supports specific component capabilities; the overall architecture and selection criteria are our engineering recommendations. Validate versions, integrations and operating requirements during design.

  1. Frappe installation prerequisites and Document API: platform dependencies, validation and permission behaviour. Agent tools must avoid bypass options.
  2. Keycloak security overview: identity integration over OIDC and SAML; business permissions still require enforcement.
  3. n8n queue mode: worker execution with Redis and a database. Reliability at a business boundary still needs reconciliation and duplicate prevention.
  4. LangGraph persistence: checkpointed agent state and production persistence choices.
  5. LiteLLM gateway: shared model access, virtual keys, budgets and logging controls.
  6. Frappe Insights: BI reports and dashboards. Shared metric governance is an implementation responsibility.
  7. OpenTelemetry traces: correlating operations across services. An operational trace is part of, rather than a substitute for, business audit evidence.
  8. Temporal workflow execution: persisted execution and recovery across failures.
  9. MCP security considerations (draft documentation): authentication and tool integration need deliberate security design.
Bring one workflow and your current system map

Where would this architecture change your business? Identify the gaps, the first pilot and the evidence needed to scale.