Orchestration & autonomy

Some work is one question and one answer. Some is a goal that needs several specialists, an hour of research, or the same task repeated over two hundred rows. Trellaris has four primitives for that — and each one is bounded, because unbounded autonomy is how agent platforms produce surprise invoices.

The orchestrator

A built-in supervisor agent. You give it a goal; it decomposes the goal, routes each step to the best agent you can see, runs independent steps in parallel, critiques the result, and synthesizes an answer with citations back to the work that produced it.

1. Plan

   The goal becomes a task graph. Planning runs on the cheap model tier.

2. Route

   Each step is matched to a candidate agent by vector similarity, then reranked by a cheap-tier model, falling back deterministically if the rerank is unavailable. Native, remote, and adapter-backed agents are all routable through one interface.

3. Execute in waves

   Independent steps fan out as child runs, each with its own session and its own event stream. The chat view shows the task tree live.

4. Critique and replan

   A critic checks the result against the goal and can trigger a replan, capped at two rounds so it cannot loop.

5. Synthesize

   A strong-tier model composes the final answer, and delegation chips in the thread show which agent contributed what.

What makes it safe to leave running

• Visibility is enforced at the router. The orchestrator can only delegate to agents the requesting user could have run themselves. Someone else's personal agent is not a routing candidate.
• Identity propagates. Child runs carry the initiating user, so a connector two hops down still acts as that person, with their own credential.
• Approvals park the whole tree. When a child hits a write, the child parks and the graph parks at its checkpoint. Approving resumes child then parent, and the write executes exactly once.
• State is durable. The graph checkpoints to the database, so a worker restart mid-plan resumes rather than restarting — and a resume onto incompatible graph code fails loudly instead of silently doing something else.
• Budgets degrade gracefully. Hitting the step cap, the family cost cap, or the wall clock produces a partial synthesis marked as budget-limited, not a truncated crash.
• Unresolvable goals ask. If the plan cannot proceed, the run parks on a question instead of guessing.

Turn it on under Build → Capabilities. Once enabled it is a normal org-ring agent, so chat, automations, channels, and inbound A2A can all invoke it without any special casing.

Background runs and Deep Research

A background run is for work that outlives a chat turn. It produces a plan first, then executes it step by step, checkpointing as it goes.

Deep Research is the built-in agent built on this: a research question becomes a plan, each subtopic is searched and read, and the synthesis turn composes findings under the citation contract. Enable it under Build → Capabilities.

Defaults (deployment-configurable)

• Up to 20 plan steps, a few turns per step.
• A one-hour wall clock when none is given.
• Up to five checkpoint resumes before the run is failed.

Fan-out

map_over takes a list — items, or the rows of a CSV — and spawns one child run per item through the same execution path, then collects the results into a single artifact on the parent.

• Failures are isolated. One bad row does not sink the batch; it is reported as a failed item.
• Idempotent. Children are keyed by step, so a retry cannot duplicate work.
• Twice-bounded. A hard cap on item count (50 by default) and a cost cap across the whole family, parent and children together (one dollar by default).
• One level deep. Child runs cannot fan out again, so the tree cannot explode.

Wake-ups

schedule_followup lets an agent arrange to be woken once, later — "check on Thursday whether the vendor replied". It becomes a one-shot automation, fires exactly once, and is visible and cancellable in the automations list like anything else. Horizon and pending-count caps come from the wakeup policy; a breach returns a tool error the agent can explain rather than failing the run.

Autonomy in practice

Autonomy is the dial that decides how much of the above happens without a person. The effective level is the lower of what the agent declares and the organization's floor.

Choosing a primitive