Case study
Coordination Hub
A workspace for coordinating work with several AIs and understanding what each has proposed, what has been reviewed and which decision is mine to make.
I started it to solve a problem in my own work: when switching between AIs, I lost context and had to reconstruct decisions. The Hub, whose experimental interface is called Testigo, brings together projects, conversations and reviewed memory. My aim is to follow the work without confusing a proposal with a verified result.
Experimental
- Pilot
- independent product in development
- L0–L3
- autonomy with human authority
- MCP
- coordination across separate sessions
Collaboration: I have worked with Claude and Codex to implement and review the system. I retain responsibility for product direction, acceptance criteria and decisions that require authorisation.
An actual interface with demonstration data. These screenshots come from Testigo's development and contain no work conversations or LALIGA information. Providers are shown as disconnected in this isolated session; the screens demonstrate the design of oversight, not an autonomous run in progress.
The project, layer by layer
Small decisions build the system.
I organise context by project and conversation. Every contribution retains its author, and I can check tool availability without leaving the workspace. Actual interface with demonstration data.
Memory distinguishes received material from reviewed knowledge. I want people to be able to inspect and review the information being reused rather than assume that everything written is valid. Actual interface with demonstration data.
Creating a separate workspace makes each project's boundary explicit. This is part of the onboarding experience that I am still testing to reduce setup and avoid mixing contexts. Actual interface with demonstration data.
Research
The problem emerged as I worked. I copied answers between assistants, repeated context and spent time checking what had actually been done. I wanted to separate three things that are often conflated: the request, the proposal and the evidence of the result.
I defined autonomy levels so that a recommendation could not turn into authorisation on its own. L0 allows observation; L1 and L2 constrain actions according to their scope; L3 reserves the highest-impact decisions for a person.
Methods:Assessment of the real cost of human mediation · Comparison with existing frameworks and the decision to build a tailored solution · L0–L3 autonomy model, with L3 reserved for a person · Measurable success criteria before writing code.
Prototype
I organised the interface around a specific task: understanding what needs my attention. Context sits on the left, the conversation in the centre and tool status on the right. Memory is consulted when needed rather than permanently occupying the reading space.
The event log preserves the operational trail. Views built on top of it let people read a conversation and review its decisions without going through the entire technical log.
AI in the process
In this project, I use AI to build a tool that also needs to help me oversee it. I alternate implementation and review with Claude and Codex, comparing their conclusions with the code and tests. Two matching answers are not enough for me to consider something validated.
- Tool
- Claude · Codex, coordinated with each other through the Hub itself
- Phase
- The full cycle: specification, implementation, cross-review and verification
- Human contribution
- Problem, acceptance criteria, decision architecture, priorities and every irreversible approval
- AI output
- Implementation, tests and independent reviews with prioritised findings and evidence
- Selection criteria
- Verifiable evidence, reversibility, project isolation, no secrets and passing tests
- Identified limitations
- No AI expands its own permissions, closes an irreversible decision or declares consensus without independent review
- Final decision
- Human authority over everything irreversible. AIs decide reversible actions and leave a trace
Development
The Hub exposes operations through MCP to read messages, record responses and contribute evidence from compatible tools. The contract distinguishes sending, receiving, processing and verifying: these are different states, and I want the interface to treat them that way too.
I have focused on recovery, retries and separation between projects. These are unglamorous situations, but they are essential if a coordination tool is not to add more uncertainty than it resolves.
Validation
A review uncovered a revealing problem: a topic could be closed as consensus without checking for an independent review. We corrected the contract to require that review and retain the evidence. This finding changed my design judgement: a positive status needs to explain what supports it.
The initial version documented 95 automated tests. This is historical development evidence, not a guarantee that the current product is finished. The Hub remains a pilot, and its ease of use still needs to be assessed with people; a screenshot or a code test cannot replace that validation.
From prototype to component
System structure
- foundations / autonomy levels · availability states · visibility classes
- organisms / attention queue · conversation timeline · consensus panel
- organisms / decision log · agent inventory · evidence chain
Code · implementation evidence
const requiredReviewers = [
...new Set(target.to.filter((agent) => agent !== parsed.from)),
]
if (requiredReviewers.length === 0) {
throw new Error('Consensus requires an independent review')
}
const reviewedBy = requiredReviewers.filter((reviewer) =>
events.some(
(event) =>
event.correlationId === target.id &&
event.from === reviewer &&
['review', 'objection', 'result'].includes(event.messageKind),
),
)
if (reviewedBy.length !== requiredReviewers.length) {
throw new Error('Consensus requires an independent review from: ...')
}
const level =
parsed.reversibility === 'irreversible' ? 'L3' : topicLevel
if (level === 'L3' && parsed.from !== 'manuel') {
throw new Error('L3 consensus may only be resolved by Manuel')
}src/store.mjs · resolveTopic()
The core of the system: the consensus gate. Previously, an agent's declaration was enough; now it requires independent review from every required reviewer and derives the level rather than assigning it.
consensusState = 'reviewed' | 'provisional' | 'lapsed' ← derived from recorded reviews, not declared by the resolving agent
Lessons learned
Separating intelligence from authority: having one party propose and another, deterministic part authorise prevents a recommendation from being mistaken for a decision.
An agreement without independent review is not consensus; it is an opinion with a stamp of approval. If the system does not check this, it will eventually happen.
Quota-related unavailability is not an exceptional case but a normal condition: the design should degrade explicitly rather than stall.
I have learned to record decisions as I work: reconstructing their context later takes more effort and can leave gaps.
Open question:What does a person need to see to confidently oversee several autonomous agents without reading everything they produce?
Contact
Let's talk.
If you think the way I work would fit your team, or you have a product or research project you would like to develop, I would love to hear about it. Tell me what you need and where you are now. I will read your message personally.
You can also find me on LinkedIn