Requiem

Inspiration

Requiem came from a real problem. My Windows installation stopped working completely. I could not get past the lock screen, and my keyboard would not let me enter anything.

I spent around three hours troubleshooting it myself without making much progress, so I asked an AI for help. That worked for the first few steps, but once we moved beyond the easy fixes, each response took longer and the problem became more complicated. I brought in a second AI to get another perspective.

That worked until their solutions started overlapping. Neither AI knew what the other had already checked, so I ended up manually passing their responses back and forth and explaining which steps had already failed.

When I finally recovered the computer, I kept thinking about how much easier the process would have been if I could have asked the question once, given every AI the same running record, and allowed them to see what the others had already tried.

That became Requiem.

I am the only human working on the project. I built it with a group of AI collaborators serving different roles, including implementation, architecture, interface design, and review. I remained the Director responsible for the product decisions, approvals, testing, and final direction.

What it does

Requiem is a desktop application for connecting and coordinating user-authenticated AI command-line tools through one interface.

The Build Week version focuses on Codex CLI, while the broader adapter system is being designed to support other compatible CLIs later.

Users can create AI seats with their own:

callsign role model workspace access level color persistent conversations

The same CLI installation can support multiple seats, and each seat can have separate conversations and model sessions without sharing context accidentally.

The War Room allows selected seats to discuss the same task with the user and with each other. It uses a controlled turn structure so the models do not continue responding indefinitely while leaving no opportunity for the user to step into the conversation.

War Room participants remain in planning and discussion mode until the user approves an action. Execution is handled separately through the ApprovalGate.

Requiem also keeps local records of conversations, approvals, activity, and which seat was responsible for each action.

How we built it

We designed Requiem with safety as one of our main concerns. When multiple models communicate, there is always a risk that something said by one model could accidentally prompt-inject another or cause it to behave unexpectedly. We wanted Requiem to coordinate those models without allowing their communication to become uncontrolled.

For now, the War Room coordinates its seats sequentially. A Director message appears immediately, then each selected model receives the relevant information and its assigned task. The model can think through the task, execute it, and return with its findings before the process continues.

Each operation is recorded in a local hash-chained Build Ledger. Important project artifacts also use Ed25519 signatures for collaborator attribution and tamper evidence. Together, these systems make it possible to track which model changed something and verify that the record has not been altered afterward.

Challenges we ran into

One of the first problems was simply detecting Codex CLI correctly. The automatic detection button initially failed even when Codex was installed and working.

After that, seats were not persistent. I could create a seat, close Requiem, and discover that it had disappeared when the application reopened. That defeated the purpose of using an existing authenticated CLI session, so I had to rebuild the persistence and session model.

I also needed a small program containing known defects for testing the review workflow. The problem was that whenever one of the AI collaborators encountered the fixture, it would helpfully announce that it had found bugs and fix them before the actual test began.

I eventually isolated the fixture inside a clearly marked folder and changed how the test workspace was presented to the seats. The fixture remains untouched until a specific task gives a model permission to inspect it.

Another challenge was separating adapters, seats, conversations, and native CLI sessions correctly. One Codex installation needs to support several seats, and every seat may need several independent conversations without leaking context between them.

During development, a signing key was also placed somewhere it should not have been. I treated the key as compromised, rotated it, and recorded what happened. That incident directly reinforced why Requiem needs verifiable authorship and an audit history rather than relying on a chat message that simply says a task was completed.

Accomplishments that we're proud of

I am especially proud that Requiem records which seat was responsible for each action.

Seat wrappers can sign project artifacts and records using Ed25519 keys. Approval information can be bound to the intended task, executable, workspace, access scope, and risk level so that approval for one operation cannot silently become approval for something else.

The ApprovalGate allows the user to inspect an action before execution. The Build Ledger records what happened afterward and links entries together so unauthorized changes to earlier records can be detected.

The War Room also gives the user control over the conversation itself. Models cannot continue passing turns forever. The user chooses the participants, the turn structure, and when a discussion should become an executable task.

I am also proud that Requiem uses the user’s existing CLI authentication. It does not need to collect API keys, replace the provider’s account system, or become responsible for storing provider credentials.

What we learned

The largest difficulty in working with several AI systems was not learning how to prompt them.

The difficult part was coordination.

Each model had its own conversation, its own partial understanding of the problem, and no reliable way to know what another model had already attempted. I became the shared memory, the router, and the audit trail.

That works for a small number of messages. It becomes exhausting once the task lasts several hours or involves several specialists.

I learned that multi-agent coordination needs explicit structures for shared context, turn-taking, permission boundaries, authorship, elicitation, and persistent records. Those ideas became the foundation of Requiem.

What's next for Requiem

The next major step is extending the adapter system beyond Codex so users can connect whichever compatible CLI they already prefer, including local models where possible.

I also plan to continue developing safeguards for communication between seats. One concern is cross-agent prompt injection, where instructions contained inside one model’s output may unintentionally influence another model. Requiem will need clear separation between discussion, trusted instructions, tool output, and approved execution.

The project is planned for release under MPL-2.0.

Another experimental feature is an optional prompt helper. It would take a spoken explanation or rough task and suggest several clearer prompt structures. It would be disabled by default and enabled explicitly in settings.

Longer term, I am exploring a small local coordination model for tasks such as preparing context packets and generating prompt suggestions. The goal would be to make it lightweight enough to run locally without requiring another paid provider.

Built With

• css
• python
• radix
• react
• rust
• tailwind
• tauri
• typescript
• vite