One model for orchestrating humans, machines and AI

Most processes worth orchestrating share one structure: some steps software completes in milliseconds, some steps a person must read and decide on, and a growing share handed to a model. Claims assessment, credit approval, content moderation, incident response and hiring all take this form, with elapsed times measured in hours or months.

Two common implementations run into the same wall. A sequence of function calls fails at the first human step, because a process cannot hold a waiting state for days. Message queues push state, retries and completion records into every individual step, and the shape of the process disappears from the source code.

Orchestration engines exist to close that gap. What separates them is how they model the world. Most split it into several kinds of step — a service step, a step assigned to a person, and more recently a step that calls an agent — each with its own lifecycle, its own way of being handed work and its own way of reporting back. The cost of integrating those kinds compounds over time and often becomes the most complex part of the system.

Binean Engine takes the opposite assumption. The work to be handed out, the capability required to perform it, and the result returned share one structure regardless of who performs it. What differs is latency and calling protocol, and both belong to the execution layer rather than to the process model.

A central nervous system does not describe how the hand grips. Its task is to establish where it stands in a chain of action, decide the next step, emit the signal and take in the response. Engine divides responsibility on the same principle.

Basal — the cortex

The sole navigation authority. No executor advances a process on its own, so process state always has a single source of truth.

Spine — the spinal cord

The event-driven conduction model: work is emitted, outcomes are collected, ordering is preserved. This is the most tightly specified part of Engine and its core.

Reflex

An agent built into the core that handles the mechanical work every process needs: conditional branching, reshaping data between steps, and invoking another process as a capability.

Agent — the executing organ

Whoever performs the work: a person, a service, or a model. At the orchestration layer all three follow one contract.

Scheduler — the body clock Not in V1

Holds every registered deadline and wakes a Process when one falls due. Without it Engine can wait but cannot move on by itself; time has to be fed in by an external actor.

Timeout — the deadline reflex Not in V1

Decides what happens when a Task runs past its deadline: cancel it and take another edge, or leave it running and open a parallel escalation branch.

This division also fixes what Engine does not cover. How a service reaches a database, how a model is invoked, and how a person signs into a form all belong to the execution layer and sit outside the model.

The first four roles are in the V1 specification. Scheduler and Timeout belong to the architecture but are not yet specified, and that is exactly why Engine loses a point on long-running processes in the evaluation below.

Flow

The process definition. Immutable, carrying an exact versioned identity; updating a process produces a new Flow rather than editing the old one.

Process

One run of one Flow, carrying its own business state as JSON data.

Task

A unit of work inside a Process. Input is validated before the work is handed out; the result returns through an independent Outcome.

Skill

The capability a Task requires, described by an input and output schema. A Flow can also act as a Skill, so processes compose.

Agent

Whoever executes a Task. Engine defines exactly one Agent concept and does not classify it; this is a design decision, covered below.

Orchestration is the responsibility of Basal. It is not a passive router: Basal actively claims a batch of events, determines the next step for each Process, then writes the entire result to the storage layer as one atomic unit. At any moment a Process is under the authority of exactly one Basal.

Machine Agent

Fastest and cheapest. A service answers in milliseconds, the cost is close to infrastructure alone, and repeated runs give the same result. In exchange it only handles work already described completely as rules.

AI Agent

Orders of magnitude slower than a machine and billed per call, but it takes on work with no clear rules yet — the work that previously required a person.

Human Agent

Slowest and most expensive, measured in hours or days, and it does not scale on demand. In exchange it is the only place with judgement for work nobody has managed to write down as rules.

That ranking has a blunt consequence: a process that leaves work with people forever pays the highest price forever. Engine’s job is therefore not only to orchestrate three kinds of executor smoothly, but to push each piece of work down to a cheaper tier once it is ready.

The mechanism is apprenticeship. While a person still holds a Skill, every execution already produces a clean input–output pair: Task.input is schema-validated and materialized exactly once, and the result returns through an independent Outcome. No extra collection tooling is needed — the training data for the successor is the incumbent’s own execution history.

And because a Skill is described by schema rather than by kind of executor, the handover never touches the process definition. A Step that points at a specialist today points at a model six months later and at a service a year after that — all three times it is the same Task requiring the same Skill. This is where the one-Agent-concept decision pays off.

Meta Agent goes one level further. It is an executor that performs no step in the process but adjusts the process itself: tuning a Step’s schema and prompt against observed results, and proposing Flow changes when the data shows a branch no longer holds. It is the one executor whose Skill is changing another executor’s Skill.

What makes that acceptable inside an audited process is the versioning decision. A Meta Agent editing a Flow does not overwrite the running definition: it produces a new Flow version, while every Process already started stays pinned to the old one. A case already handled is never retroactively handled differently because the system tuned itself. Without that constraint, letting a system rewrite its own process is not something you can put in front of a compliance function.

To be clear about status: apprenticeship and Meta Agent are in the design, not in V1. The V1 specification goes only as far as making them possible — a single Agent concept, Skills described by schema, and immutable Flow version identity.

Engine is not tied to a particular line of business. Fit is determined by the structure of the problem rather than the sector: processes that run long, involve several kinds of executor, and must leave an auditable record throughout.

Business processes with approvals

Claims, credit, procurement, hiring. Systems assemble the file, people decide, systems carry out the result.

AI in the loop

A model proposes, a person approves or rejects, and that judgement returns as training data. Requires a pause point for a human without keeping a process alive for the duration of the wait.

Operations and incident response

An alert opens a process, part of it runs automatically, and part of it halts for confirmation before anything touches a system in service.

Coordinating multiple AI agents

Several agents pursuing one goal, needing a single record of who holds which piece of work, what is complete, and who has authority over the next step.

The list above is design scope, not a customer list. The first deployment is BENOVA, Binean’s insurance core modernization programme. Insurance was chosen as the opening application because it concentrates several hard constraints into one system: processes lasting years, multi-level approvals, strict audit requirements, and infrastructure that cannot be replaced in a single move.