OathLock

Where your coding agents work together across providers, under your control.

Comment

Inspiration

AI coding agents are becoming capable of completing long and complex tasks. Developers of all levels are beginning to use multiple agents such Codex, Claude Code, and Grok paired with other local tools for the same repositories. The problem is that the agents act like isolated workers. A dev can assign tasks to multiple agents but it is difficult for the dev to answer operational questions like are two agents duplicating or conflicting with each other's work and causing the code to be messed up? Can agents request specific help from one another? What evidence supports a agent's claim that it completed a task the way it was intended? I built OathLock to explore a different model. A private work network where coding agents from different providers can coordinate through bounded assignments, well-structured signals, durable records, and human-reviewed evidence. OathLock doesn't replace coding agents, Git, Cl systems, or human reviewers because those systems still perform, validate, and approve the work. OathLock provides the coordination and accountability layer around them.

What it does

OathLock connects approved agent identities to a repository workspace and places their work inside a controlled workflow. A developer can connect an agent using the OathLock CLI, load repo-specific rules before the run begins, define the task, agent and permitted scope, start and observe a controlled run, allow an agent to request bounded assistance from another connected agent, review the evidence returned by each agent, approve, reject, or challenge a finding, and retain a Run Passport containing the reviewed record while the agents can also submit structured evidence that describes the commands executed, command results, files changed, tests. limitations, and supporting findings. OathLock validates and normalizes this evidence before it can be approved.

How I built it

OathLock is a full-stack TypeScript application built with Next.js, React, TypeScript, Supabase, PostgreSQL, RLS, Vercel, xterm.js, and a npm-distributed command-line interface. The local OathLock CLI connects supported agent environments to be hosted application. The CLI can connect an agent through a human-approved request, install repo-native instructions, load active repository rules, start and update controlled runs, read an agent inbox, publish and replay Work Signals, accept, reject, and complete assignments. The architecture is event-driven. Routine coordination is handled through deterministic state transitions and structured records rather than additional language-model calls. Model usage will remain inside the connected providers and is invoked when an agent must perform actual work. Codex was used extensively for implementation, debugging, database integration, CLI development, server routes, testing, analysis, and documentation. Claude Code was also used for bounded reviews, including read-only checks of repository areas and Watchfloor boundaries. OathLock governs work performed on its own repository as well. This dogfooding process allowed the product to encounter the same stale runs, incomplete evidence, and provider failures that it is intended to manage.

Challenges I faced

Distinguishing real agent activity from visual activity

It is easy to create an interface that makes an agent appear active even when no provider process is running. A connection is not the same as presence and presence is not the same as work and work isn't the same as a successful completion. OathLock therefore derives meaningful states from authenticated retained events rather than just animations or browser timers.

Coordinating agents without creating unlimited token consumption

A poorly designed multi-agent system can become expensive very fast. Agents might repeatedly send full context, duplicate work, or recursively delegate tasks. OathLock defaults to a solo workflow and places specific boundaries around coordinated work such as max supporting agents, delegation depth, request count, duration, estimated-token ceilings, minimal context packets, and human approval thresholds. Findings are also returned by reference whenever possible so full context isn't repeatedly copied between agents.

Preserving human control without blocking every action

If human approval was required for every event that would make the system unusable but allowing unrestricted automation would eliminate human oversight. We separated coordination from material decisions. Deterministic events can progress through the system automatically, while sensitive actions such as approving evidence, dispatching certain assignments, and/or adopting findings remain visible and reviewable.

Supporting multiple providers honestly

Different providers expose different command-line interfaces, authentication systems, lifecycle events, quotas, and automation capabilities. OathLock uses a provider-neutral adapter contract but it still represents the verified capabilities of each provider. Supporting a protocol does not automatically prove that every provider lifecycle, launch path, or failure has been verified.

Building OathLock with by using OathLock

Dogfooding the whole thing revealed problems that were not obvious in the original design. Such as runs attaching to stale sessions, evidence being returned after expiration and being reused across assignments, provider attribution becoming unclear, approval being confused with final review, and something missing being mistaken for a successful launch. Each failure forced me to make the system represent more of the real agent lifecycle instead of hiding anything uncertain behind the interface. One of the most important design decisions was refusing to present simulated activity as real agent behavior. When an integration, command, provider, or lifecycle has not been verified, OathLock records that limitation instead of manufacturing a successful state.

What we learned

The largest lesson was that multi-agent coordination is not primarily a chat problem. Agents do not need unlimited conversations but instead they need structured answers to a number of questions. Such as what work is being attempted, what is allowed vs not allowed, what evidence needs to be returned to the user, and who decides whether a result is used or not? I also learned that agent identity, connection, presence, execution, and evidence all must be treated as separate concepts. Another lesson I learned was that human approval can't be decorative and needs a system that clearly identifies what is being approved, and what's the evidence that supports it so the human stays in control. Finally, I learned that representing failure honestly improves the product.

What’s next for OathLock

The next major step is deeper cross-provider bounded delegation and making the Rules automated

The intended workflow

  1. Codex begins a controlled implementation run
  2. Codex requests a bounded security review
  3. OathLock checks repository access, provider capability, owner policy, coordination limits, and resident availability.
  4. An authorized local adapter launches or resumes Claude Code
  5. Claude performs a linked supporting run within the permitted scope
  6. Claude then returns a structured finding and supporting evidence
  7. Codex adopts, rejects, or challenges the finding
  8. A human reviews the resulting evidence
  9. OathLock records the complete causal chain in the Run Passport
  10. The supporting agent returns to an inactive state. The same protocol can later support additional providers with verified adapters. The long term goal is to make OathLock the private work network where coding agents from different providers can operate together under human ownership, boundaries, and an accountable record that can be used by any model of the supported providers so new models pick up the rules and previous records keeping the flow efficient.

Built With

Share this project:

Updates