FLEXVOTIXGet started
Planned / Phase 1

Coordinate agents with a plan you can check first.

AEGIS Orchestrator is designed to turn an objective into a stored, validated plan, and to delegate each step with only the authority it needs. Models may help draft a plan. They do not get the final say on whether it is valid.

ObjectiveRoot MandatePlannerCompiles planResearchInvoicesResearchVendorsAnalysisFinds overdueVerificationvendor.verifyVerificationpo.matchDecisionProposes onlyGuardDecidesHumanApprovesExecutionExact actionsObjectiveRoot MandatePlannerCompiles planResearchInvoicesResearchVendorsAnalysisFinds overdueVerificationvendor.verifyVerificationpo.matchDecisionProposes onlyGuardDecidesHumanApprovesExecutionExact actions

Task decomposition

The Planner turns one objective into a versioned plan of steps. A plan is data, so it can be validated before any step runs.

Plan validation

Bad plans fail before they cost anything.

An agent loop finds out it was wrong by doing the wrong thing. A plan can be rejected in advance. Add a fault and see it caught.

Plan v1: invoice review, 6 steps

Plan valid

Schema, agent versions, dependencies, Mandates and budget all check out, so the plan is stored and scheduled.

Simulated. Error text shows the intended style.

Two kinds of plan

Autonomy expands as evidence allows.

Unconstrained planning is not in the first release. Bounded plans are easier to validate and to trust.
Phase 1

Static

A developer defines the graph. The run fills in the data.

Use when the process is known and repeatable, such as month-end reconciliation.

Phase 1

Bounded planner

A planning step chooses from allowed templates, and the output is validated.

Use when the approach varies but its limits are clear, such as support triage.

Phase 3

Dynamic replanning

The plan can change mid-run. Each new version is validated and cannot widen authority.

Use when evaluations show that it is safe for the task.

Example workflow

What happens to an objective.

  1. Receive

    An objective arrives with a root Mandate and a principal.

  2. Compile

    A definition or planner produces a draft graph of steps.

  3. Validate

    Schema, published agents, dependencies, budget and Mandates are checked.

  4. Schedule

    Steps with no unmet dependencies become ready, and workers lease them.

  5. Join or replan

    Results flow to dependents. Failure policy decides whether to stop, skip or request a new plan version.

Technical explanation

The moving parts.

Plans are rows, not a running process. Each plan version is stored with its steps. State lives in PostgreSQL, so any worker can continue the work.

Transitions are atomic. A step's result and the steps it unlocks are committed together, so a crash cannot leave a half-finished join.

Delegation derives authority. When a step is scheduled, a child Mandate is created from its parent and checked to be a subset.

Agents share through records. A step reads the recorded outputs of its dependencies, and each handoff can be inspected.

Have a multi-agent process that keeps breaking?

Tell us about it. We are looking for early access teams with real orchestration problems.