The record has the final say.
Use the authoritative system's validation for every change. Give each data domain an owner.
For technology teams · The reference behind the five Agentic Automation workflows
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 ERP owns the transactions. Agents work within a defined scope. People own policy and exceptions. Identity, action controls and audit apply across the design.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Every action crosses a boundary the model cannot override. Check the caller, the business rule and the required approval.
All passValidate & execute
Any failHold or reject
Use the authoritative system's validation for every change. Give each data domain an owner.
Filter documents, records and tools by the caller's scope. Recheck permission when an action executes.
Prompts guide behaviour. The action gate enforces limits, approvals and permitted destinations.
Show a person the proposal, evidence and business effect. Record the decision and its scope.
Track correct outcomes, human effort, rework and operating cost. Keep trace data proportionate and protected.
Prevent duplicate effects. Test recovery, reconcile uncertain outcomes and keep a manual route available.
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.
| Responsibility | Start with | What makes it work |
|---|---|---|
| Business records | ERPNext + Frappe MariaDB · Redis | Owned master data, validated application APIs and tested backups. Keep existing authoritative systems where useful. [1] |
| Identity | Your 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 gate | A 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. |
| Integration | Frappe jobs + APIs n8n for connector workflows | Persist important work, handle retries and reconcile results. Connector execution does not replace ERP validation. [3] |
| Agent execution | A 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 access | A 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 & metrics | Frappe 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] |
| Evidence | OpenTelemetry + ERP audit Representative evaluation cases | Correlate requests across services. Redact sensitive data, control access and retain business evidence to the agreed policy. [7] |
Consider Temporal for long waits, recovery and coordination across services. Keep duplicate prevention in the receiving business service. [8]
Introduce a warehouse, shared semantic service or search index when volume, multiple sources or retrieval quality justify the operating cost.
Choose replicas, a broker or a cluster against measured load and recovery objectives. A pilot needs a proven restore path from day one.
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.
Define the workflow, permitted actions and customer inputs. Agree an estimate and the ongoing operating responsibilities.
Output: a pilot scope, baseline and success measures.Test representative and difficult cases: missing data, hostile attachments, duplicate requests and failed steps.
Output: a traced pilot and evaluation results.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.The agent prepares.
A person executes.
A person reviews.
The workflow executes.
Low-risk actions proceed.
Exceptions go to the owner.
We assess the existing systems first. Integration is often enough; a migration needs a clear business reason of its own.
It depends on the process, data quality, integrations and required controls. Scope, estimate, timing and responsibilities are agreed in writing before implementation.
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.
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.