Let us clear up a vocabulary ambiguity first, because it causes many misunderstandings in this market. At UNYX, orchestration means the machine that executes. Orchestrator means the qualified person who pilots that machine inside your company. The two words look alike, they do not mean the same thing, and the second one is a job.

The components, in the order a request crosses them

  • A single entry point. Form, email, messaging, a call from another piece of software: everything arrives through one gateway that authenticates, validates the format and records.
  • A database that holds authority. Every request becomes a row there, with its state. Agents never work on a copy sitting somewhere else.
  • A queue. Anything long, expensive or failure prone goes through it, with retries and a reasoned abandon.
  • Specialised agents. One agent, one mission, one set of tools. Not a single agent that would know how to do everything.
  • A layer of deterministic rules. Placed between the agents and the outside world, it refuses forbidden actions before they leave.
  • A log. Every action carries its author, its reason, its cost, its result.

Where the data is stored

In a relational database hosted in the European Union, with access rules applied row by row: a user can only read what their role allows, and that check happens on the server, never in the browser. Documents and attachments live in private storage reachable only through signed, temporary links.

Model calls carry only what the task needs. This point is worth putting to any provider: sending an entire database to a model to answer a simple question is both costly and needlessly risky.

How the agents communicate

Not by chatting to each other in natural language, which is spectacular in a demo and unmanageable in production. They communicate through the state of the request in the database: an agent reads a state, produces a structured result, writes the new state. The next one takes over.

The advantage is decisive at diagnosis time: you can open any request and read exactly who did what, in what order, with what result. A conversation between agents leaves no such trace.

A system you cannot read back afterwards is not a system. It is a black box with invoices.

Permissions

Three levels, all necessary. The user level, with roles and entitlements verified on every request. The agent level, where each agent receives the strict minimum of tools and access its mission requires. And the action level, where operations with external effects go through the rules layer, whatever their origin.

That last level is the most important, and most often missing: the same check must apply to an action launched by an agent and to one launched by a human from the interface. Otherwise security depends on the route taken, which amounts to having none.

Errors

Retry with backoff on transient failures, reasoned abandon and an alert beyond that, a documented fallback when a model is unavailable, a confidence threshold that hands over to a human, and a real undo of reversible actions. We describe this mechanism, and the lesson that produced it, in the article on errors.

How to check

Ask for a demonstration in three screens, not a presentation: the log of a real request from start to finish, the screen where a human validates an action, and the behaviour of the system when an error is forced. A provider who has built that can show it immediately. Our AI Orchestrator page explains the rest: who pilots, with what commitment, and on whose access the AI runs.