Give an agent a job. Give the system boundaries.

The interesting question is not whether an AI agent can call a tool. It is whether an organization can explain which actions the agent is authorized to take, what evidence supports them and how errors are detected and corrected.

What is the agent actually authorized to do?

Give each tool action a narrow contract. Increase autonomy only when evaluation supports it and the exception path has already been engineered.

Authority must be earned at each step.

Permission to interpret does not confer permission to act.

  1. Read

    Retrieve permitted account and policy context

    Required gate
    Identity + source-level access checks
    Failure boundary
    Denied or missing context → no inference of access
  2. Interpret

    Classify a request or extract candidate facts

    Required gate
    Bounded schema + input/output validation
    Failure boundary
    Uncertain interpretation → review queue
  3. Propose

    Draft a response or a change

    Required gate
    Visible evidence + explicit proposed state
    Failure boundary
    Unsupported proposal → correction or refusal
  4. Execute

    Apply only the approved, scoped change

    Required gate
    Business rules + required human authorization
    Failure boundary
    Partial or unknown write → reconcile, then recover
Illustrative authority ladder for a case workflow. Higher authority is a different engineering commitment, not an automatic maturity goal.

A rules engine may be the better agent.

Stable structured decisions often need conventional software. A workflow orchestrator with one bounded model call can be easier to verify than a sprawling multi-agent system.

Inspect the exception before the happy path.

  • An action-permission matrix and tool contracts
  • Malicious document text, unauthorized tools and duplicate replay
  • Timeout, partial failure, escalation and rollback behavior

The complete agents and workflows argument

For CTO, CIO, CPO, COO

The situation behind the request

A customer request arrives by email with several documents. A team must classify the issue, check account context, prepare a response and update a case-management system. An AI application could reduce manual interpretation, but every action touches data, policy and customer consequences.

Where the obvious solution falls short

A fully autonomous happy-path demo can conceal inconsistent tool responses, prompt injection, repeated transactions, missing identity context and vague ownership. A production workflow cannot assume the model will always choose the same tool for the same situation.

How we would approach the work

We map the workflow as states and deterministic business rules. AI handles bounded interpretation or draft tasks. Tools are available only through scoped interfaces. Human reviewers approve consequential changes. Each step has idempotency, timeout, retries and explicit failure handling.

What the engagement may include

  • Task/job charter and action-permission matrix for agent tools.
  • Workflow engine or orchestration plan with deterministic gates and retry semantics.
  • Review UI for uncertain or high-consequence outputs.
  • Evaluation cases, transaction logs, rollback and operational observability.

The choices worth making explicitly

A conventional rules engine is often better for stable structured decisions. A workflow orchestrator plus a small model call may outperform a sprawling multi-agent system. Autonomy should increase only where real evaluation evidence supports the change.

What we would test before calling it ready

Test malicious content in retrieved documents, unexpected tool output, unauthorized requests, duplicate action replay, partial integration failure and safe human escalation. Follow current OWASP guidance and applicable security review.

A sensible first step

Begin with a single workflow and one genuinely difficult step. Implement the exception path before promising that the system can run unattended.

Bring us the
difficult part.

A product idea, a broken workflow, scattered company knowledge or an integration others keep working around. Tell us what needs to change and what has already been tried.

Discuss a project