WHY A COLONY?
The colony makes coordination visible. In my software, the connections are explicit: typed handoffs, scoped context, parallel tasks, shared state and verification. I design where a model can propose work, where application code controls execution and where a person must approve an action.
Explore the 3D colony ↗01 / THE PROCESS
DEPTH 1 / Task and context · 1/4
I turn a user need into a task with inputs, constraints and an observable outcome. Before adding an agent, I decide what a successful response must contain and what would make it unsafe or misleading.
DEPTH 1 / Task and context · 2/4
I separate the current request, retrieved evidence and persistent user context. They have different lifetimes and different authority. The agent receives the context needed for its task; retrieved text remains evidence, not an instruction source.
DEPTH 1 / Task and context · 3/4
I define the structure another component can consume. A finding needs an observation, its supporting source and a proposed response. Schema validation checks structure; evidence checks must still establish whether the content is supported.
DEPTH 2 / A vertical slice · 4/4
I connect intake, orchestration, a structured result and the interface before expanding the system. One complete run exposes broken contracts and missing states that isolated agent demos can hide.
02 / THE PROCESS
DEPTH 1 / Agent contracts · 1/7
I split responsibilities at meaningful boundaries: gathering context, producing a result and checking it. Each handoff defines the input, the expected output and the authority of the receiving component.
DEPTH 1 / Agent contracts · 2/7
I make the execution order explicit. A component waits for its required inputs; independent work can proceed concurrently. Business actions sit behind their own checks rather than depending on a model’s promise to behave.
DEPTH 2 / Shared state · 3/7
Adra runs five specialist auditors concurrently. Each emits structured findings. The synthesizer waits for that stage, combines the findings and normalizes them into one risk register before the critic examines it.
DEPTH 2 / Shared state · 4/7
I distinguish what belongs to this execution from what should survive the session. Working context, past episodes and knowledge about the learner serve different queries. Retrieval selects what the next agent needs instead of replaying the entire history.
DEPTH 3 / Execution control · 5/7
I use concurrency when tasks have independent inputs, then an explicit join before the next dependent stage. More agents do not automatically reduce latency: the slowest required branch still affects completion.
DEPTH 3 / Execution control · 6/7
Adra’s critic names a missing audit target, the affected operation and the reason to revisit it. The runner launches targeted work, incorporates new findings and synthesizes again. The loop has a maximum of three critic passes.
DEPTH 3 / Execution control · 7/7
I ask the synthesis stage to reconcile overlapping findings while preserving their sources and remaining gaps. Multiple agents agreeing is not independent evidence when they share a model, a prompt assumption or the same incomplete context.
03 / THE PROCESS
DEPTH 1 / Verification · 1/5
I separate generation from verification and use checks suited to the claim: symbolic math, curriculum references and semantic checks. A model’s confidence can guide triage; it cannot establish factual correctness.
DEPTH 1 / Verification · 2/5
A reviewer needs a distinct question and a way to affect execution. I separate checking support for a claim from asking the generator to restate its answer. Review output must identify what should be corrected or examined further.
DEPTH 2 / Review and approval · 3/5
I keep recommendations and consequential actions on separate paths. A person reviews the proposal; application code checks whether the approved action may execute. A prompt asking for permission is not an authorization mechanism.
DEPTH 2 / Review and approval · 4/5
I distinguish an empty result, a failed check and a supported conclusion. A system that reaches its iteration limit may still have unresolved gaps. Those gaps belong in the state shown to the person reviewing the output.
DEPTH 3 / Authority · 5/5
I scope the context an agent receives and the actions the application exposes. Retrieved content and user text do not grant permissions. Server-side validation decides whether an action is allowed, even when the model proposes it confidently.
04 / THE PROCESS
DEPTH 1 / Evaluation and budgets · 1/8
I turn known failures into repeatable cases: unsupported claims, incorrect math, conflicting context and attempts to override instructions. I examine both missed errors and false alarms. A test harness is useful only when its evidence matches the claim being made.
DEPTH 1 / Evaluation and budgets · 2/8
I decide which checks belong on the response path and which can run asynchronously. I also bound concurrency and repeated work. The tradeoff is explicit: deeper verification costs time and resources, and delayed checks need a clear delivery contract.
DEPTH 2 / Product and memory · 3/8
A working agent still needs an API, state persistence, an interface and a coherent response to failure. I connect these parts so the user can follow what is happening and understand whether the work completed.
DEPTH 2 / Product and memory · 4/8
I decide which observations should change persistent state and which belong only to a run. A memory update needs a purpose and an owner. Learning about a user is different from treating every generated statement as a durable fact.
DEPTH 3 / Evidence and release · 5/8
I preserve the link between a finding, the operation it concerns and its supporting source. A citation field makes a result inspectable; further checking must establish that the source actually supports the claim.
DEPTH 3 / Evidence and release · 6/8
A prototype can validate orchestration without proving reliability. Before broadening a release, I examine partial failures, access boundaries, recovery, evaluation coverage and the behavior a user sees when a dependency fails.
DEPTH 4 / Operations · 7/8
I expose stage transitions, intermediate outputs and resource usage. This makes it possible to locate a slow branch or an unproductive review loop. A final response alone hides how the system arrived there.
DEPTH 4 / Operations · 8/8
A prompt, model or schema change can alter downstream behavior. I use explicit interfaces and repeatable cases to examine that impact. Maintaining the system means revisiting its assumptions as well as its code.
THE APPROACH IN PRACTICE
LEARNING PRODUCTS · INQUISITIVE FLOW LEARNING
FREE TOOLS FOR EDUCATORS
PUBLISHING
FLEET OPERATIONS