Operating map

Where the agent actually works.

An agent is not a tool sitting next to the process. It sits inside it — on the repeatable part, between the systems you already run, with a person at the end of every exception. This page shows that position three ways: as a node, as a before and after on one flow, and as the control tower you watch it from.

Start the operating audit →
What is on this page
  1. aWhere an agent sits in the process
  2. bBefore / after on one flow
  3. cControl tower — two layers

Every number on this page is a model example and is labelled as one where it appears. None of it is measured operation at a client.

01The agent node

The loop an agent runs, and the point where a person steps in.

The order is the whole design: a trigger arrives, data is read from the systems you already run, the agent handles the repeatable part, a decision is made against your rules, an action is written back — and a person is pulled in only when the case is an exception. Everything the loop does stays in the record.

The loop, in words
  1. 01Trigger
  2. 02Systems and data
  3. 03Agent
  4. 04Decision
  5. 05Action
  6. 06Human exception
  7. 07Outcome
What the colours mean
  • Turquoise — an active step, an approved state
  • Blue — integration and data flow
  • Purple — a human exception
  • Red — a blocked state, an integration that is not available
Your systems · continuous operationlive
Your systemsERPCRMDocumentsEmailWarehouseAccountingHelpdeskWebOperating layerabove your systemsSalesconfirms a price outside the price listFinanceapproves a document above the limitOperations leaddecides on exceptions01Triggeran email, a request, a document, an event02Systems and datacontext read from ERP, CRM, email03Agentextracts, matches, prepares the output04Decisionagainst rules that are written down05Actionwritten back into the system06Human exceptiononly the unclear or risky case07Outcometraceable and measurable
  • Systémy v jádru · vaše data
  • Agenti ve smyčce · rutina 24/7
  • Člověk jen při výjimce · rozhoduje
02Before / after

One flow, counted twice.

The comparison is not about the speed of a single step. It is about how many steps, people, systems and hand-offs are left standing once the flow is finished.

Model example

The figures below are a model example, built to show the format. They are not measured operation at a client. They describe one typical flow — four people, three systems, two hand-offs — so the shape of the comparison is clear before your own flow replaces it.

Model flow:an incoming supplier invoice, from arrival to posting
TODAY:7 steps / 4 people / 3 systems / 2 hand-offs
WITH ENTER:3 steps / 1 agent flow / human only on exception
The same flow, step by step
  1. 01

    The invoice arrives

    TODAYIt lands in a shared mailbox. Somebody has to notice it first.
    WITH ENTERThe arrival is the trigger. The flow starts itself.starts itself
  2. 02

    The document is filed

    TODAYDownloaded, renamed and saved into the folder somebody remembers.
    WITH ENTERRead straight from the mailbox and attached to the case.integration
  3. 03

    Header and lines are entered

    TODAYRetyped by hand into the ERP from what the document already says.
    WITH ENTERExtracted and written into the ERP without anyone retyping it.agent flow
  4. 04

    Matched to the order and the delivery

    TODAYHand-off one: purchasing compares the order and the delivery note by eye.
    WITH ENTERMatched against the order and the delivery note by rule, in the same pass.agent flow
  5. 05

    Approved above the limit

    TODAYHand-off two: emailed to a budget owner. The invoice waits until they answer.
    WITH ENTEROnly what falls outside the rules stops — and it arrives with the case and the reason attached.human exception
  6. 06

    Posted in accounting

    TODAYEntered a second time, now in the accounting system.
    WITH ENTERPosted from the same record. Entered once, not twice.agent flow
  7. 07

    The supplier is told

    TODAYSomeone answers the supplier's follow-up email, if there is time for it.
    WITH ENTERThe confirmation goes out and the pass is closed in the record.record

Model example. The steps, the counts and the roles above are illustrative. Nothing here carries a source, a period or an accountable person, so none of it is a result — it stays a model until an audited flow of your own takes its place.

03Control tower

Two layers: what each agent does, and what management has to be able to see.

An agent without a control tower is a script somebody trusts. The lower layer is the operating detail of one agent. The layer above it answers the five questions a management team actually asks — and it answers them from the same record, not from a status meeting.

Layer 1 — management view
  • 01

    What is running?

    Every flow in production, its owner, and the last pass it completed.

  • 02

    What is failing?

    Failed passes, and the rule or the integration that caused them.

  • 03

    What needs human judgment?

    The exception queue: what stopped, on what grounds, and who it waits on.

  • 04

    Where are we gaining capacity?

    Where volume moved from people to agents — and where it did not move at all.

  • 05

    Where is risk increasing?

    A rising exception rate, a blocked integration, an agent with no named owner.

Layer 2 — per agentModel example

Sample data. The agents, the counts and the values below are a model example of what the control tower shows per agent — not a running client operation. The owner field carries a role, not a person, because a name is assigned at handover.

Supplier invoice intake

Running
Cases processed
1 240 / last 30 days
Success rate
96.2 %
Exceptions
47, all closed
Handover to a human
41 cases → the finance role
Time saved
≈ 190 hours / 30 days
Economic effect
≈ 1.1 FTE of capacity returned (modelled — no rate agreed yet)
Owner
Finance lead — a role, not a name. The name is assigned at handover.
Audit trail
Every pass logged: input, rule applied, decision, approver, output.

Quote from an incoming request

Exceptions queued
Cases processed
310 / last 30 days
Success rate
88.4 %
Exceptions
36, of which 12 still open
Handover to a human
36 cases → the sales role
Time saved
≈ 60 hours / 30 days
Economic effect
≈ 0.35 FTE of capacity returned (modelled — no rate agreed yet)
Owner
Sales operations lead — a role, not a name. The name is assigned at handover.
Audit trail
Every pass logged, including the price the rule refused to confirm.

Order confirmation to the customer

Blocked
Cases processed
0 since the integration became unavailable
Success rate
not measured while blocked
Exceptions
every case routed to a person
Handover to a human
full volume → the customer service role
Time saved
0 while blocked
Economic effect
no effect while blocked (modelled)
Owner
Customer service lead — a role, not a name. The name is assigned at handover.
Audit trail
The block is in the record too: when it started, what is unavailable, who was told.

Model example. Every value in the cards above is sample data. A number leaves this page as a result only once it carries three things: where it came from, what period it covers, and the name of the person accountable for it.

The map is phase one

Bring one flow and we will map it.

Not this model flow — yours. Phase one produces the same three views with your steps, your hand-offs and your numbers, and every number arrives with a source, a period and a named owner.

Start the operating audit →