AI Agents Need a Conductor: Taking Agentic AI to Production

An AI agent knows how to pick a tool and take an action. An organization needs to know who approved it, what changed, what happens on failure, and how to stop it. That is why an agent that impresses in a demo is still not a system you can run in production.

The gap between a demo and a business process

AI agents extended the language model from producing text to acting: calling an API, retrieving information, updating a record, and deciding the next step. The more an agent can do, the clearer its operational framework has to be.

Inside an organization, an action never stands on its own. There are permissions, SLAs, system dependencies, sensitive data, exceptions, and accountability. Connecting tools, enforcing permissions, and coordinating agents across these dependencies are part of the orchestration work.

Four layers that keep an agent on track

1. Action boundaries: a minimal list of tools and permissions for each step.
2. Process state: an explicit, persistent record of progress that does not depend on conversation memory.
3. Quality control: structural validation, business rules, and tested quality thresholds before execution. A model’s self-reported confidence is not enough.
4. Exception path: retries, time limits, compensating actions, and handover to a person (human-in-the-loop) without losing context.

The key is separation of responsibilities. The process engine owns sequence, state, and policy; the agent handles tasks requiring language understanding or flexible judgment; deterministic services carry out critical actions.

Example: handling a customer request

The agent classifies the request and proposes a resolution. The process engine assesses the risk level: a simple request is answered automatically; a financial change requires verification and approval; uncertainty opens a task for a human service representative.

In this design, record the relevant inputs, decisions, tool results, approvals, and model version, with access and retention limits. This makes actions easier to investigate; logs alone do not explain a model’s internal reasoning or guarantee recovery.

Process-first architecture with Camunda

With Camunda, the contract between the agent and the organization can be expressed in BPMN. The agent does not “run everything”; it operates inside a long-running process with modeled waiting points and approval steps. Camunda user tasks let the process wait for a person before continuing. Changes to running processes still need version and migration planning.

That is how we at NG Workshop build AI you can operate responsibly: AI inside the process, not instead of the process.

Further reading (Hebrew sources)

• Geektime: How to build AI agents with JavaScript
• Geektime: The challenges of running AI workers in the enterprise
• Calcalist: AI agents and cross-system processes

Summary

• An AI agent needs boundaries, process state, and an exception path.
• The process engine and the agent play different, complementary roles.
• Logging and control are part of the architecture, not an add-on after launch.

Got an agent that works in a demo? Let’s turn it into a business process