Agents in the Back Office: CRM, ERP and Ticketing via APIs

In the DATEV export for MAFU-SHERPA, four unremarkable rules decide whether the accounting file is accepted: debit and credit markers, the German decimal separator, empty DATEV fields and the required column order. The application we built transforms the Business Central export, shows a preview and lets accounting review the file before handover. It does not write silently into the target system. This published DATEV case is a better starting point for back-office agents than the idea of a universal digital employee. It separates reading, transformation, review and handover. An agent may accelerate individual steps, but the business rules and approval stay outside its own judgement.

Read broadly and write narrowly

OWASP names three causes of excessive agency in LLM03:2026 Excessive Agency: excessive functionality, excessive permissions and excessive autonomy. Its controls are concrete. Tools should be small and purpose-built, permissions should stay minimal, consequential actions should require approval, and code rather than model judgement must enforce authorisation. For the DATEV workflow, that means the agent may read an approved Business Central export, apply the known rules and generate a preview. It needs neither access to all accounting entries nor an open-ended "make any API call" tool. Handover remains a separate logged step.

Approval follows reversibility

The OpenAI guide to building agents rates tools by factors including write access, reversibility, account permissions and financial impact. Applied to CRM, ERP and ticketing, that does not produce one blanket "human in the loop" rule. Each action gets its own boundary:

• Read only: customer data, order status or ticket history may be queried through a dedicated read identity.
• Reversible write: after pilot review, an internal note or follow-up may run automatically if it can be removed unambiguously.
• Prepare customer-facing work: a quote, reply or credit note is created as a draft with the supporting data.
• Financial or legal effect: sending, posting, payment and contract changes need named approval.
• Unclear state: after a fixed number of failed attempts, the agent stops and escalates instead of continuing to try.
• Idempotency: a step run twice must not create a duplicate order. That belongs in the API, not in hope.

An agent-ready business application therefore needs clean entities, unambiguous IDs, roles, state models, audit and event logs, webhooks, test environments, rate limits and safe write paths.

Automate no action in the first pilot that moves money or makes a customer commitment.

A faster draft already creates useful relief and exposes the business exceptions.

Identity belongs in the audit trail

An MCP connection does not yet answer whose identity the agent uses. The MCP security guidance dated 28 July 2026 forbids servers from simply passing through tokens issued for another service. Such token passthrough bypasses checks and makes downstream logs look as though another identity acted. Permissions should start small and expand incrementally. Give the agent its own technical identity per system and purpose. The audit trail must connect the records read, tool call, result and approving person. Germany's BSI likewise recommends minimal and separated access, approval gates and regular log review in its guidance on AI agents.

Check for the three dangerous ingredients

In the back office, untrusted content, private data and an external communication channel can quickly meet. A support agent may read an outside email, see customer data in CRM and send a reply. This is the combination in Simon Willison's "lethal trifecta". A filter alone is not a dependable answer. Remove one leg instead: the reading agent may save a draft, but it may not send. The DATEV case makes the separation concrete. The input file is read, the output is generated through fixed rules and the preview is reviewed. Only then does a person hand it to DATEV. The same pattern fits a quote draft, ticket reply or credit note.

A pilot needs cases, not a demo

Choose several real cases, including missing data, duplicates, contradictory prices and a repeated tool call. For each one, write down in advance which draft may be produced, which warning must appear and what must never execute. Then inspect the generated record in the target system or preview.

Never accept only the agent message. A study of coding agents documented inaccurate self-reporting in real sessions. That is not a measured error rate for back-office work, but it gives a clear verification rule: "ticket updated" counts only when the ticket ID, new status, audit entry and any approval are visible in the system.

The interface is the weak point in the benchmark too

In the independent TheAgentCompany benchmark, agents attempted 175 tasks in a simulated software company. The strongest tested system completed 33.8% of GitLab tasks fully, but only 12.9% in the ownCloud web office interface. The environment was synthetic and used a 2025 model generation, so the absolute figures will age. The difference nevertheless shows how strongly the working interface affects the result.

The practical starting point therefore remains small: one existing workflow, a dedicated read identity, one narrow tool, a reviewable draft and named approval. The pillar on APIs over screens explains the technical background. The DATEV case shows how little autonomy is needed to remove real work. If you want to scope a back-office case of your own, discuss a concrete workflow with us.