Memory(One)
Get in touch
Back to insights

Agentic Workflows

AI agents need budgets, logs and a kill switch

AI agents are not ordinary software users. They can consume tokens, call tools, repeat loops and trigger actions. They need operational controls before they enter production.

Published
  • Operate & Maintain
  • AI Governance

An AI agent is not just another SaaS user.

A normal user opens a tool, performs a task and stops. An agent may read context, call a model, search documents, use tools, update systems, evaluate its own output and repeat the loop. If it is connected to business systems, it may also trigger workflow actions.

That can be valuable. It can also become expensive, opaque and risky if no one has defined how far the agent may go.

AI agents need budgets, logs and a kill switch before they enter real operation.

The cost model is changing

Traditional software procurement often assumes predictable subscriptions: a fixed licence, a known number of users and relatively stable monthly cost.

AI changes that assumption. Many AI systems are priced by usage. OpenAI and Anthropic publish token-based API pricing. GitHub announced that Copilot plans would transition to usage-based billing from June 2026, with usage calculated from token consumption, including input, output and cached tokens. Cursor’s pricing page describes included model usage with on-demand usage billed in arrears after included amounts are consumed.

This does not mean AI is necessarily too expensive. It means AI cost behaves more like cloud consumption than a fixed software seat.

An agent can amplify that cost because it may work through multiple steps. A single task may include retrieval, reasoning, tool calls, validation, retries and output generation. A faulty loop, broad context window or poorly bounded task can multiply consumption.

The operational risk is not only financial

Cost is the easiest risk to understand, but it is not the only one.

An agent connected to systems also has access risk. It may read customer data, finance data, employee data, product data or source code. It may call tools through service accounts. It may prepare changes for another system. In some designs, it may execute actions directly.

OWASP identifies “Excessive Agency” as a risk in LLM-based applications: too much functionality, too many permissions or too much autonomy can let damaging actions happen in response to unexpected or manipulated outputs. OWASP also highlights prompt injection and sensitive information disclosure as relevant risks for LLM applications.

These are software architecture concerns. They are not solved by good intentions or by calling the system an assistant.

Minimum controls before production

Before an AI agent becomes part of a workflow, the business should define minimum operational controls.

1. Owner

Every agent should have a named business and technical owner. The owner is responsible for the purpose, access, monitoring, review and retirement of the agent.

If no one owns it, it should not operate.

2. Business purpose

The agent should have a narrow, explicit purpose. “Help with finance” is too vague. “Classify incoming supplier invoices and prepare approval notes for human review” is clearer.

A specific purpose makes access, budget and measurement possible.

3. Access scope

The agent should have the least access needed for the task. Read-only access should be preferred unless write access is essential. Separate service accounts, role-based permissions and environment boundaries should be used where appropriate.

Access should also be reviewed periodically.

4. Cost budget

Each agent should have a budget. This may include daily, weekly or monthly spend limits, per-task token limits, model-selection rules and alerts when consumption changes unexpectedly.

The important point is that cost should be visible before the invoice arrives.

5. Rate limits

Agents should not be able to call models or tools without limits. Rate limits reduce the impact of faulty loops, repeated retries and unexpected usage spikes.

6. Logs

The system should log relevant inputs, outputs, tool calls, approvals, errors, model usage and system actions. Logs are needed for debugging, cost control, auditability and trust.

7. Alerts

Unusual behaviour should produce alerts: unexpected cost increase, repeated failures, high-risk actions, unusual access patterns, repeated retries or abnormal task volume.

8. Human approval thresholds

Not every action needs human approval. But high-impact actions do. The company should define what an agent may observe, recommend, prepare or execute only after approval.

9. Escalation route

When the agent cannot complete a task, it should have a clear escalation route. That may be a human owner, a support queue, an exception dashboard or a fallback process.

10. Kill switch

There should be a way to stop the agent quickly. This may disable a workflow, revoke credentials, pause scheduled runs, block write actions or switch the system to read-only mode.

A kill switch is not a sign of distrust. It is normal operational control.

11. Periodic review

Agents should be reviewed like other operational systems. The review should cover cost, value, accuracy, exceptions, permissions, vendor dependency, model changes and whether the workflow still makes sense.

Shadow AI becomes more serious with agents

Shadow AI is often discussed as employees using unapproved chat tools. That is already a data and security concern.

With agents, the risk increases. An employee may connect an AI tool to documents, repositories, inboxes, browser sessions or workflow systems. If that connection is outside normal IT and operational control, the company may lose visibility over data access, cost, output quality and system actions.

The practical response should not be to block all experimentation. The response should be to give teams a safe route: approved tools, clear boundaries, reviewable use cases and a path from prototype to production.

Supplier and portability risk

Agentic workflows can become dependent on a provider’s pricing, models, APIs, latency, terms and availability. That does not mean every company needs a complex multi-model architecture from day one. But it should avoid unnecessary lock-in where the workflow is important.

Practical questions include:

  • Can the workflow use a cheaper model for simpler steps?
  • Can prompts, retrieval logic and business rules be separated from one provider?
  • Can the system fall back to a manual process?
  • What happens if pricing changes?
  • How easy is it to switch model providers or disable advanced features?

These are design questions, not only procurement questions.

A simple autonomy model

A useful way to design agentic workflows is to separate levels of autonomy:

  1. Observe: AI reads and summarises information.
  2. Advise: AI recommends a next step.
  3. Prepare: AI drafts or prepares an action for review.
  4. Act with approval: AI executes only after a human confirms.
  5. Act autonomously: AI executes within narrow, monitored boundaries.

Most business workflows should start at the lower levels. Autonomous action should be reserved for low-risk, well-bounded and monitored tasks.

The practical takeaway

AI agents can create value when they support real workflows. But they should be treated as operational software, not as experimental assistants that run indefinitely.

A production-ready agent needs a purpose, owner, access boundary, budget, logs, alerts, approval rules, escalation route and shutdown mechanism.

If the business cannot see, limit, review or stop the agent, it is not ready for production.

Sources and inspiration

Next step

Need a practical route from article topic to working software?

Memory(One) helps organisations review, modernise and build the systems their teams depend on.

Get in touchView servicesRequest a Technical Review