Inside the Koios Super General Agent: Complexity Evaluation and DAG Execution
Enterprise AI orchestration has a routing problem. A focused request should not wait for a swarm of workers, while a multi-stage deliverable should not be forced through one long, fragile chat loop. The super general agent architecture in Koios addresses both cases by choosing an execution path that fits the work: handle straightforward tasks inline through a ReAct-style loop, or decompose complex goals into a dependency-aware task graph.
This is not a claim that one mode is universally better. Inline execution minimizes coordination for small, bounded work. Delegation creates parallelism and explicit dependencies when a request has independent workstreams or important sequencing. The design goal is to use the smallest execution structure that can reliably complete the task.
Why one-size-fits-all agent patterns underperform
A monolithic agent can be effective for a single query or a short sequence of tool calls. As work expands, however, it must keep more intermediate state in one execution path, manage ordering itself, and recover from partial failures. Conversely, sending every task to multiple agents adds orchestration overhead even when the task is just a quick lookup or small file change.
| Pattern | Good fit | Trade-off |
|---|---|---|
| Inline ReAct | Bounded requests, a few dependent operations, quick checks | Simple control flow, but a long workflow remains concentrated in one execution |
| Task DAG | Multi-deliverable goals with independent work and explicit prerequisites | Parallel work and visibility, but requires task definition and coordination |
These are routing choices rather than competing philosophies. A reliable agent operating system should preserve a direct path for simple work and offer structured delegation when complexity justifies it.
Complexity evaluation as an execution decision
Koios describes the Super General Agent as evaluating cognitive complexity before choosing its path. In practical terms, the orchestrator considers whether a goal can be completed by a short sequence of actions, whether there are multiple distinct outputs, whether parts can proceed independently, and whether later steps depend on earlier results. The key architectural decision is not “How many agents can we launch?” It is “What execution structure gives this request a clear and verifiable completion path?”
A request to inspect one file and summarize a section is naturally inline. A campaign involving source analysis, article drafting, image creation, publication, and an editorial-log update has separate work units and ordering constraints. Some units can run in parallel; publication must follow content and asset preparation; tracking and verification depend on the publication result.
User goal
├─ bounded actions, one coherent output ──> inline ReAct + CLI
└─ distinct workstreams / dependencies ──> task DAG
Research ──> Draft + Visual (parallel where appropriate)
└─> QA ──> Publish ──> Verify and recordInline execution: keep bounded work lightweight
For a task with a small, predictable action sequence, the agent can operate directly: discover the relevant command or connector, inspect the required schema where applicable, execute, and check the result. A single CLI surface across filesystem, tools, knowledge, canvas, and task operations helps keep those steps explicit and repeatable.
Inline execution is not an excuse to skip verification. If a request edits a document, inspect the changed text. If it calls an external service, confirm the returned state. The advantage is that no task graph is created when there is no meaningful concurrency or dependency management to gain.
DAG execution: make dependencies and parallelism explicit
When a goal contains multiple deliverables, a directed acyclic graph represents work as tasks and dependencies. Independent tasks can be scheduled together; dependent tasks wait for their prerequisites. Milestones can group stages such as ingestion, generation, and review, while task identifiers provide stable references for dependencies.
| Workflow concern | Explicit DAG treatment | Operational value |
|---|---|---|
| Independent work | Place tasks in the same phase without unnecessary dependencies | Allows safe parallel execution |
| Required order | Declare prerequisite task IDs as dependencies | Prevents downstream work from starting prematurely |
| Stage visibility | Group tasks beneath milestones | Clarifies progress and deliverables by phase |
| Completion | Track each task outcome and verify final artifacts | Reduces ambiguous “done” states |
A DAG is useful only when the graph reflects real constraints. Adding dependencies between unrelated tasks destroys parallelism; omitting real prerequisites creates race conditions. A good plan makes the minimum necessary ordering visible.
Designing robust task payloads
Task payloads should be specific enough that each worker can act without guessing: define the action, input location, expected output path, and acceptance criteria. Use stable IDs and make dependencies reference those IDs. Keep mutable shared files out of parallel branches unless writes are disjoint or otherwise coordinated.
{
"id": "draft_article",
"title": "Draft the technical article",
"kind": "custom",
"dependencies": ["research_sources"],
"payload": {
"action": "content_generation",
"sourceFile": "/workspace/research-notes.md",
"outputFile": "/workspace/article.html"
}
}This example illustrates the shape of a task contract, not a promise that every deployment uses identical payload fields. The execution engine’s supported schema should be inspected before scheduling. The general principle is portable: name the work, point to its context, specify its output, and encode prerequisites.
Reliability comes from observable completion
Delegation creates a new failure mode: work may be incomplete, delayed, or reported ambiguously. Treat completion as structured state, not conversational reassurance. For each task, check its status and confirm expected output artifacts exist before allowing dependent work to proceed or declaring the overall workflow finished.
Failure handling should also be scoped. If a research branch fails, a dependent draft should remain blocked rather than proceeding on invented context. Independent branches may still finish. The orchestrator can then retry or report the failed component while preserving completed outputs. Human approval belongs at a deliberate review boundary when editorial, legal, or operational policy requires it.
How to choose the right execution path
- Use inline ReAct when the request is bounded, has a small number of known steps, and benefits little from parallel work.
- Use a DAG when work separates into independently actionable units, has dependencies that must be respected, or needs milestone-level progress.
- Keep the graph narrow by adding only meaningful tasks and prerequisites.
- Define completion criteria for outputs, external side effects, and verification.
- Protect shared state by assigning clear ownership for each file or record.
This framework avoids both extremes: monolithic execution that hides structure, and unnecessary agent swarms that increase coordination cost without improving outcomes.
From agent reasoning to an execution harness
Complexity-aware routing is one part of a broader Enterprise AI Harness. Koios positions orchestration alongside Just-In-Time tool discovery, workspace-based context management, zero-trust controls, and relationship-based authorization. For related background, see Just-In-Time tool discovery, SingleFlight request coalescing, and ReBAC-governed client portals.
For broader orchestration design, the reliable question is not whether an agent can think through a task. It is whether the operating system can select an appropriate execution mode, expose dependencies, preserve state, and prove that each deliverable completed. Inline ReAct and DAG task queues work best as complementary tools within that harness.
Conclusion
The Super General Agent pattern is a pragmatic orchestration contract: keep small work direct; decompose complex work into explicit tasks; run independent work concurrently; enforce prerequisites; and verify results before closing the loop. That combination gives enterprise teams a path from flexible model reasoning to structured, auditable execution—without paying the coordination cost of a swarm for every request.
