1.1 Billion AI Actions Later: Why Enterprise Agentic Work Needs a Control Layer

On September 24, 2026 Workato announced at its World of Workato (WOW) 2026 conference that its customers have processed more than 1.1 billion enterprise AI actions as of September 2026, with more than 886,000 users on the platform. Both figures are vendor-reported internal platform data rather than audited third-party measurements, and should be quoted with that caveat. The theme of the conference was turning intents into business outcomes, but the more interesting subject for engineering teams is the architectural choice behind the number: a neutral control and execution layer that sits between models and the enterprise systems those actions touch.

1. What the Number Actually Says

Start with the provenance. The 1.1 billion actions and 886,000 users come from Workato's own platform data, so they describe one vendor's customer base rather than the market. The architectural trend they point at is nevertheless checkable. Workato positions itself as a control and execution platform for enterprise AI, and its argument is straightforward: enterprises already run on the order of 17,000 systems that AI needs to act upon. If every agent integrates directly, holds its own credentials, and defines its own retry and audit behaviour, scale does not buy efficiency, it buys loss of control. Lenovo, VOIS (Vodafone Intelligent Solutions), and Red Hat presented their own deployments at the conference, and Anthropic, OpenAI, and AWS explained how models pair with a control and execution layer.

# Define the business intent once, declare what the agent may do, and let
# the platform decide the path. This is the difference between a workflow
# that a business owner can read and a prompt nobody can audit.

intent: resolve-duplicate-invoices
trigger:
  source: erp.invoices            # 17,000-odd systems is the real integration problem
  where: "status = 'pending' and duplicate_of is not null"
agent:
  role: reconcile
  may:
    - read:  [invoices, vendors, purchase_orders]
    - write: [invoices.status, notes]
    - call:  [email.send_template]     # named tools only, never a generic shell
  must_not:
    - payment.execute                  # money movement is out of scope, by design
limits:
  max_actions_per_item: 6
  max_usd_per_item: 0.05
  on_exceed: escalate_to_human

The theme was turning intents into business outcomes

2. Why You Need a Separate Control Layer

Wiring an agent straight into a system of record is most teams' first version and most teams' first problem, for three reasons. The first is permission: an agent running as an individual inherits everything that person can do, not the handful of actions this task requires. The second is retry: the failure enterprises fear is not an error but a duplicate, an invoice processed twice or a record created again. The third is audit: when a business owner asks why this invoice was merged, an answer that requires reading prompt history is not an operable answer. Code sample 1 encodes all three at once in an intent definition: what may be read, what may be written, which named tools may be called, and one explicit red line that payment execution is out of scope. The named-tool constraint is the one teams skip and the one that pays off most, because a list of tools is reviewable in a way that a general-purpose shell is not.

// A control layer earns its name by deciding, per action, before anything
// runs. Route by cost and capability, then enforce the intent's limits.
// The agent never talks to a system of record directly.

export function planAction(action, intent, ctx) {
  const policy = [
    { name: "scope",   ok: intent.may[action.kind]?.includes(action.target) },
    { name: "forbid",  ok: !intent.must_not.includes(action.op) },
    { name: "budget",  ok: ctx.spentUsd + action.estUsd <= intent.limits.max_usd_per_item },
    { name: "calls",   ok: ctx.calls + 1 <= intent.limits.max_actions_per_item },
    { name: "data",    ok: ctx.fields.every((f) => allowedField(f)) },
  ];
  const failed = policy.filter((p) => !p.ok).map((p) => p.name);
  if (failed.length) return { run: false, escalate: true, reasons: failed };

  // Model routing belongs here, not in the prompt. Cheap work first.
  const model = action.complexity === "low" ? "fast-tier" : intent.agent.model;
  return { run: true, model, idempotencyKey: hash(action, ctx) };
}

3. Decide Before the Action Runs

A control layer proves itself in its ordering: it decides before execution rather than recording after it. Code sample 2 lays out five admission checks, covering whether the action is inside the declared scope, whether it trips a forbidden operation, whether it would breach the per-item cost ceiling or the call ceiling, and whether the fields being read are permitted. If any check fails the action escalates to a human rather than letting the model decide on its own. The same function makes a second decision, model routing, which belongs in the control layer rather than in the prompt, so that the routing rule can be adjusted centrally, measured, and rolled back. The on_exceed rule in code sample 1 and the escalate branch in code sample 2 are two ends of the same policy: exceed the limit, hand it to a person, do not let the agent gamble.

# Token and action cost are operational metrics, not finance trivia.
# With 1.1 billion actions reported, a one-cent drift per action is a
# seven-figure line. Meter per intent, per action, and per tenant.

def meter(intent, action, usage, tenant):
    cost = usage.input_tokens * IN_RATE + usage.output_tokens * OUT_RATE
    events.emit("ai.action", {
        "tenant": tenant,
        "intent": intent.name,
        "action": action.op,
        "model": action.model,
        "tokens": usage.input_tokens + usage.output_tokens,
        "usd": round(cost, 6),
        "cache_hit": usage.cached,
    })

def nightly(tenant):
    report = rollup(tenant, window="1d")
    # Guardrail: alert before the invoice, not after.
    if report.usd > BUDGET[tenant] * 0.8:
        notify(owner_of(tenant), {"at": "80% of monthly AI budget", **report})
    # Rewrite the expensive path if the cheap one matched quality.
    for step in report.top_cost_steps(5):
        if step.cheap_tier_win_rate > 0.95:
            propose_routing_change(step)

A neutral layer has to carry risk, cost, and scale

4. At 1.1 Billion Actions, Cost Is an Engineering Metric

Once action volume reaches nine figures, cost stops being a finance topic. Code sample 3 treats tokens and action cost as operational telemetry, metered per tenant, per intent, per action, and per model, with cache hits recorded alongside. It then sets an alert at 80% of a monthly budget so the owner hears about it before the invoice arrives, and it adds the part teams usually miss: if a step's cheap tier wins on quality more than 95% of the time, propose changing the routing. That matches what the industry keeps finding about inference cost architecture, which is that most of the saving comes from putting a request in the right tier rather than from negotiating rates. Code sample 5 sets two floors on the execution side. Every effectful action is idempotent so a retry cannot double-charge, and high-risk operations pause for a human, with that pause written to the ledger rather than living in someone's inbox.

// Every AI action that touches a system of record needs an entry that a
// human can read six months later. This is what makes "who changed this
// invoice, and why" answerable without reading a prompt.

type ActionRecord = {
  at: string;
  tenant: string;
  intent: string;            // resolve-duplicate-invoices
  actor: { kind: "agent"; id: string; model: string; version: string };
  approvedBy?: string;       // present only when a human gated this step
  inputs: { ref: string; hash: string }[];   // hashes, not payloads
  decision: string;          // merged | kept | escalated
  effects: { system: string; object: string; before: unknown; after: unknown }[];
  usd: number;
  idempotencyKey: string;    // replay-safe, and that is not optional
};

// A neutral execution layer is only neutral if the record is portable:
// same schema whether the agent was Anthropic's, OpenAI's, or your own.

5. Audit Records a Business Owner Can Read

Code sample 4 defines the record shape, and two trade-offs in it are deliberate. First, inputs are stored as references and hashes rather than raw payloads, which satisfies audit requirements without scattering sensitive data a second time. Second, approvedBy exists only when a step actually passed a human gate, so its absence is itself meaningful information that the step ran autonomously. The schema also carries actor.version, which answers which version of the agent did this, and idempotencyKey, which answers whether it happened twice. Workato's CEO Vijay Tella framed the layer as neutral, a place to mitigate risk, improve token costs, and scale AI. Red Hat's Sherry Gentry-Gasper gave the more direct advice of building the governance and execution foundation first and letting adoption scale on top of it. The comment in code sample 4 makes the same point from the other direction: the layer is only neutral if the record is portable, the same schema whether the agent came from Anthropic, from OpenAI, or from your own team.

#!/usr/bin/env bash
# Two rules that separate a demo from a production control layer:
# 1) every effectful action is idempotent, so retries cannot double-charge
# 2) risky actions pause for a human, and the pause is recorded, not emailed

set -euo pipefail

run_action() {
  key="$1"; op="$2"; payload="$3"
  if ledger.seen "$key"; then
    echo "replay ignored: $key"       # already applied; do not apply twice
    return 0
  fi
  if [ "$(risk "$op")" = "high" ]; then
    decision=$(await_approval --intent "$INTENT" --op "$op" --timeout 30m)
    ledger.record "$key" "$op" "$payload" "approved_by=$decision"
  fi
  effects.apply "$op" "$payload"
  ledger.record "$key" "$op" "$payload" "applied"
}

# Vendor data point: 886,000+ users touch this layer. At that scale,
# "we usually remember" is not a control. Idempotency and approval are.

One execution layer in front of tens of thousands of systems

6. A Checklist for Building the Layer

First, express business intent as a reviewable definition with allowed actions, forbidden actions, and limits, as in code sample 1. Second, put admission decisions before execution and keep model routing there too, as in code sample 2. Third, meter cost per tenant, intent, action, and model, with an alert at 80% of budget, as in code sample 3. Fourth, write an audit record per action that stores hashes rather than payloads and names the model version, as in code sample 4. Fifth, enforce idempotency and human approval for risky operations, and record the approval in the ledger, as in code sample 5. Sixth, treat the layer as a product you iterate on rather than a script you finish. WOW expands in October to London, Singapore, Amsterdam, Tokyo, Tel Aviv, and Sydney, and enterprise AI control and execution is becoming a cross-regional infrastructure conversation, which is simultaneously a governance problem and a delivery-speed problem.