Agentification is an operating change, not a chat interface
A useful business agent must understand the authorised customer, order, invoice, case, policy, workflow state, and available next actions. It must then operate through a controlled surface that preserves the application’s rules and ownership.
Screen automation can help during discovery, but it is a weak foundation for governed operations. Stable resource identifiers, typed APIs, structured errors, and explicit actions give the organisation a surface it can authorise, test, monitor, and support.
Select one narrow, valuable workflow
Choose work that is frequent, measurable, painful, and connected to clear records and owners. Good starting points often include reconciliation preparation, order exceptions, case updates, sales follow-up preparation, document completeness, or knowledge-supported service.
Do not begin with a general instruction to make the ERP agentic. Name the consumer, business outcome, system of record, risk level, accountable owner, and acceptance evidence for one end-to-end workflow.
Assess every required capability independently
An application may have mature read APIs and unsafe write actions, or strong business logic with no supported external interface. Classifying the whole system as ready or not ready hides these differences.
Use five treatments: reuse a sound capability; harden an existing one with missing controls; extend it with context or workflow coverage; build a supported interface where none exists; or block an operation that should remain human-controlled.
- Reuse: adequate context, controls, and verification already exist
- Harden: the operation exists but trust or safety controls are incomplete
- Extend: the interface is sound but lacks needed workflow coverage
- Build: no suitable supported machine interface exists
- Block: required safeguards cannot be enforced or exposure is inappropriate
Use a progressive trust ladder
Start with scoped reading. Then allow the agent to draft or stage work without making it official. Add a preview that shows the exact proposed change or consequence. Require approval for consequential execution. Finally, read the authoritative state back and preserve audit evidence.
This progression separates preparation from authority. It lets the organisation prove context quality, action design, validation, human review, and operational support before increasing autonomy.
- Read
- Draft or stage
- Preview
- Approval-gated execute
- Readback and audit
Keep enforcement inside the application
Agent instructions should explain the rules, but the ERP or CRM must enforce authentication, tenant boundaries, resource permissions, validation, transaction logic, approval state, idempotency, and prohibited actions across every execution surface.
Agent-facing APIs should call the same domain services and persistence logic used by supported human or product interfaces. A parallel business-logic path can produce inconsistent records, weak authorisation, and audit gaps.
Design for uncertainty and recovery
Business operations include stale data, duplicate requests, partial failure, long-running work, concurrent changes, expired approvals, and unknown outcomes. The action contract should state what is safe to retry, how a request is identified, when a preview expires, and how final state is verified.
For material actions, retain the requesting actor, delegated agent, resource, inputs, policy decision, confirmation, result, exception, and readback without leaking secrets or unnecessary customer data.
Validate service maturity and agent trust separately
A reliable API does not automatically create a reliable agent. Test the service contract, permissions, tenancy, transaction behaviour, and recovery independently from the agent’s context selection, planning, tool use, evidence, escalation, and human acceptance.
Release to a restricted audience first. Expand workflow scope or execution authority only when monitored results meet agreed quality, safety, latency, cost, and operational-support thresholds.