CONCEPT · OWNER-DEFINED ARCHITECTUREOrchestration + coding agent

Klaus

AI orchestration and coding agent for coordinating development workflows, agent and model handoffs, implementation tasks, and verification.

01 · Understand

Work starts from a stated intent, not a prompt pile: what should exist, what must not change, and how it will be judged done. Klaus is designed to keep that intent as the fixed point every later step is checked against.

The class of work it stands for: automating technical workflows — task routing, context handoff between agents, review and validation — the same thinking I apply when scoping automation for a client. It is a concept here, not a delivered system.

02 · Research

A coding agent is only as good as the context it carries. Klaus is designed to hold project context — repository state, rules, prior decisions — and hand the relevant slice to each agent, instead of asking every agent to rediscover it.

The core of the concept

03 · Route

Klaus sits between intent and execution. It splits work across roles — an architect, an implementer, a reviewer — and routes each to whichever agent or model is configured for that role.

InputUser intent
OrchestratorKlaus
- Architectagent / model
- Implementcoding lane
- Reviewvalidator
Target stateVerified output

Concept diagram of an owner-defined architecture — no live providers, models or integrations are shown or claimed.

04 · Implement

The coding lane turns an approved plan into changes, in bounded steps. It is meant to work against the same context and rules the plan was written under.

05 · Review

Implementation is never its own judge. A separate review lane inspects the result against the intent and the project rules before anything moves on.

06 · Validate

Validation is a gate, not a summary: checks run, results are read, and a step that cannot be verified is reported as unverified rather than assumed to pass.

07 · Handoff

Each cycle ends with a record: what was asked, what changed, what was verified, and what remains — so the next session, or the next agent, starts from facts.

Understand
Research
Route — key stage
Implement
Review
Validate — key stage
Handoff

Current status

CONCEPTUAL · NOT IMPLEMENTED HERE

Klaus is presented as an owner-defined role and architecture. No public repository, verified run, or live provider or model integration is claimed on this page.

CONCEPTUAL WORKED TRACE

One hypothetical task, seven stages

Example taskBuild an internal client dashboard.

This shows how the workflow is designed to move a task. It is a design illustration, not a record of work Klaus performed.

01 Understand
Input
A request in the owner's words.
Action
State what must exist, what must not change, and how done will be judged.
Output
Scoped task with acceptance criteria.
02 Research
Input
Repository files, project rules and truth boundaries.
Action
Select only the slice each role needs.
Output
Compact context packet.
03 Route
Input
Scoped task and context packet.
Action
Split the work by role and assign each role to its configured agent or model.
Output
Architecture, implementation and review lanes.
04 Implement
Input
Approved technical plan.
Action
Make the change in bounded steps, under the rules the plan was written with.
Output
Candidate change.
05 Review
Input
Candidate change and the original intent.
Action
Inspect the result in a separate lane — implementation never judges itself.
Output
Issues and corrections.
06 Validate
Input
Corrected change.
Action
Run the checks and read the results; report what cannot be verified as unverified.
Output
Check, build and test results.
07 Handoff
Input
Verified change and its evidence.
Action
Record what was asked, what changed, what was proven and what remains.
Output
Final report and next state.