Funktionserklärungen 01: Die Orchestration Engine von Agent Argo

From the first task to the verified patch

Agent Argo is not a single model that works on a task for as long as possible. It is a system that translates software work into understandable steps: plan, break down, process, test, correct, and only then submit for adoption.

With this post the series "Functional explanations" begins. It makes the central mechanisms of Agent Argo understandable – not as marketing promises, but along the lines of their actual use. The kickoff is the orchestration engine: the process that turns a request into a controlled work process.

flowchart LR
    A[Auftrag] --> B[Einstellungen vor dem Lauf]
    B --> C[CEO erstellt Plan]
    C --> D[Task-Graph und Reihenfolge]
    D --> E[Kontext, Modellwahl und Bearbeitung]
    E --> F[Fehlerbehandlung und Korrektur]
    F --> G[Review und Verifikation]
    G --> H[CEO fasst zusammen]
    H --> I[Patch prüfen oder anwenden]

1. Before Starting: Setting Quality, Costs, and Autonomy

Before Argo processes a task, two decisions must be made. They are deliberately kept separate:

1. How should Argo balance cost against result quality?
2. How autonomous may Argo be in a project?

This prevents a typical trade‑off: a thorough run does not automatically receive more write rights, and an autonomous run does not automatically choose expensive models.

The Three Levels for Cost and Quality

The Model Router knows three understandable modes. They change how strongly price and model level influence the selection; the required skill always remains central.

The operational profiles Fast & cheap, Balanced, and Thorough bundle this router mode with further decisions: whether joint reasoning is only observed or actively executed, whether verification is binding, and whether Argo should escalate more strongly on a failure.

The Three Levels of Autonomy

Autonomy does not dictate what Argo deems correct, but when it needs a human.

In code these rules are implemented more precisely as readonly, confirm_write, auto_write, and bypass. The three levels make them usable; the project policy remains the final authority. It can, for example, exclude cloud providers, allow only local models, block network access, limit commands, protect secrets, or set a cost limit.

2. The CEO Level Turns the Request into a Plan

The user first describes the goal in natural language. Argo's CEO level receives a limited project overview, the available model catalog, and relevant project information. It can ask clarifying questions first or generate a plan.

A plan contains more than just a to‑do list. Each task gets a role, a description, dependencies, and required skills – for example coding, planning, qa_review, or context_comprehension. For difficult tasks a higher difficulty can also be noted. The CEO level does not rigidly name a model: it describes the work, while the router later decides which model fits each task.

3. From Plan to Task Graph

After plan approval, Argo transforms the tasks into a task graph. A node may only run once its dependencies have succeeded. Independent tasks can run in parallel.

The scheduler orders ready nodes according to a comprehensible utility heuristic: expected quality minus cost, time, and risk penalties. If a node lies on the critical path, it receives priority in case of ties because it determines the overall runtime.

In cases of high uncertainty or high risk, Argo may select a joint reasoning mode before processing: multiple perspectives develop approaches, critique each other, and provide a justified work plan for the worker. Whether this is only logged or actually executed is decided by the operational profile chosen before the run.

4. Before Each Task: Appropriate Context, Skills, and Model

Before a worker starts, Argo builds a context tailored to the role and task. This includes relevant files, dependency results, and – if enabled – a compact memory package as well as appropriate skill instructions. Argo does not blindly dump all project knowledge into the prompt. Memory and skills are selected based on relevance, origin, recency, cost, and security status.

Then the model router selects a model. First, candidates are excluded that are not reachable, lack sufficient context window, have exhausted their quota, or violate the active policy. From the remaining models, Argo evaluates four factors:

• Skill Fit: How well is a model rated for the required skills? When multiple skills are involved, the average is taken.
• Cost: How expensive is the request – or, under active cost routing, the expected successful result?
• Model Level: Difficult, security‑critical, architecture, and review tasks may prefer a flagship level.
• Experience: After enough real results, the recent success rate and repeatability of a model/skill combination are taken into account.

For cost calculation, Argo can use the Expected Cost of Success: direct price, expected retries, verification effort, possible rework, and a small latency penalty. Thus a cheap single call is not automatically the cheapest solution if it fails more often or triggers rework.

An explicit model recommendation is accepted only if it is available, allowed by policy, and large enough for the context. Planning, delegation, and context understanding by the CEO level again use a strong model specially selected for these three abilities.

5. The Worker Processes the Task in Small, Verifiable Steps

A worker does not work with a single answer. It goes through a limited ReAct loop:

1. The model proposes structured actions – such as reading, searching, executing tests, or writing changes.
2. The executor checks permission, path, command risk, and active policy.
3. Argo only executes allowed actions.
4. Results, diffs, and error messages flow back to the model as observations.
5. Based on this, the worker corrects its next step or finishes the task.

Thus an agent can, for example, first read the relevant code, then make a change, run a test, and incorporate the test result into the next decision. The full process remains visible in the run log.

The output itself is also checked. If a model provides invalid action JSON, Argo can request a limited repair loop. In strict mode, a permanently faulty output is deliberately rejected, rather than treating unclear text as an action.

6. On Errors: Targeted Correction Instead of Blind Retry

Not every failed task means the entire run has failed. The orchestration engine distinguishes error causes and reacts controllably:

• A temporary error can be retried within fixed limits.
• A hard verification finding provides its concrete objection as a task for the next attempt.
• With cascade enabled, the next attempt adopts the insights of the previous one instead of starting from scratch.
• After a failure, Argo may prefer a stronger model.
• If a budget is exhausted, no expensive blind retry is started: the node ends with a documented partial result or becomes visibly escalated.

The node strategy finally decides whether a task can be skipped, fails controllably, or requires user decision. Dependent tasks receive only confirmed partial results. This prevents a local error from turning into a silent error that propagates through the rest of the plan.

7. After Implementation: Review, Verification, and a Possible Additional Cycle

Once the planned tasks have been processed, Argo inspects the integrated state from multiple perspectives:

• The QA Agent may read files and execute test commands.
• The Architecture Agent inspects the structure read‑only and deliberately has no write rights.
• Deterministic verifiers can run tests, type checking, or linting as objective oracles.
• Model‑based and deterministic findings are combined into an overall judgment.

If QA, architecture, or a binding verifier finds issues, Argo assigns the findings to the affected tasks. Only those tasks are reprocessed with the concrete feedback. Then review and verification happen again. Without a consensus mode, this loop is limited; in a deliberately chosen consensus mode it continues until the user stops or the reviewers agree.

A verifier in observation mode documents findings but does not block. In a binding mode, a hard finding can prevent the result from being considered successful. This allows adjusting strictness per operational profile without losing traceability.

8. Only After Verification: Documentation and CEO Summary

After a completed work and verification cycle, a documentation agent can record the changes. Then the CEO level creates a summary for the user: What was accomplished? What remained open? Which tests ran? Which files or decisions are involved?

The result is more than a chat text. The run provides a shared identifier for plan, model selection, cost, actions, verification judgments, user interruptions, and later patch decisions. This makes it possible to trace how Argo arrived at a result.

9. In the End, a Human Decides on the Real Workspace

By default, Argo works in an isolated worktree. The changes are there as a patch, not silently in the real project. Depending on the autonomy level, one of three things then happens:

• The patch remains ready for adoption, partial adoption, further editing, or discard.
• A successful patch is automatically adopted.
• In conflicts with later changes, Argo stops visibly; it does not overwrite foreign changes.

A failed run is not automatically applied. Even a highly autonomous configuration does not lift the policy: secret protection, command rules, provider limits, budget caps, and necessary human gates remain effective.

What the Orchestration Engine Provides

The orchestration engine does not only decide which model answers next. It connects user intent, settings, planning, parallelization, model selection, tool usage, error correction, quality assurance, and safe adoption into a coherent process.

The metric is not “as many agents as possible”. Additional work occurs only where it is justified: a stronger model for a difficult architecture decision, a second reasoning approach in uncertainty, a targeted retry after a verifier objection, or a human approval before a risky action.

The course is thus set.