# I want my coding agents to work together

By Horia Jurcut · 29 September 2026

I have subscriptions to Codex and Muse. I want them to work on different parts of the same change, share what they learn, and bring the result back together. That sounds simple. The interesting part is everything around it.

Sprowt Harness · Design notes · September 2026

I’m designing **Sprowt Harness**, a local tool for coordinating coding agents. You would open a repository, run the harness in your terminal, and start a feature or a fix. Several of those conversations could run at once. Each could use Codex, Muse, or both.

The first place I want to use it is [Sprowt, the finance product I’m building](https://minimumeffort.dev/blog/building-sprowt). The harness itself is independent of that product. It should work with other repositories, and I’d like to open source it as it develops.

This is the proposed architecture. There is still work to do before I can claim the full system works.

## Why build this?

Partly because I want to build faster. If a frontend change and a backend change can move independently, I want to let them. I also want the agents to question each other’s assumptions and check the combined result.

And partly because I want to learn. My background is in distributed systems. Queues, state, coordination, recovery: those are familiar problems, but adding models makes the boundaries interesting again. What happens when I change the requirements halfway through? Which worker needs to know? What survives a restart?

More agents won’t automatically mean better code, or even less waiting. I want to measure time to a verified change, how much rework integration creates, and how often I need to step in. Those are the outcomes I care about.

## Explore the architecture

A **coding harness** is the software around a model that gives it tools, context and a way to keep working. Codex and Muse already provide that for individual agents. Sprowt Harness would coordinate several of those agents across a project.

Explore the [interactive diagrams](https://minimumeffort.dev/blog/building-sprowt-harness#architecture) on the website. Text descriptions of the overview and all ten components follow this article. Each connection names what moves between the steps.

## A few useful terms

**Code mod**: One feature or fix, with its own conversation, queue, plan and workers.

**Worker**: A Codex or Muse session assigned part of the work.

**Worktree**: A separate checkout of the repository. Workers can edit without overwriting each other’s files.

**Sandbox**: An environment that restricts what a worker’s code can access and run. A worktree alone does not provide that protection.

**MCP**: Model Context Protocol: a common interface through which agents can discover and call tools.

## Parallel work needs a place to meet

A code mod could assign an API change to Codex and the interface to Muse. Each worker would have its own workspace. They would exchange questions, replies and artifact links through a shared mailbox exposed by MCP tools. The mailbox would keep sender identity and recipient information, while each worker keeps its own model conversation. The two-way arrows in the overview and Worker execution diagrams show this connection.

A provider adapter would deliver each message into an active turn when supported, or queue it for the next turn. Delivery tracking would stay separate from whether the worker understood and acted on the message. Code and test reports would remain in Git and artifact storage; messages would carry references to them.

I want to be able to queue messages, edit or reorder the ones that haven’t been delivered, and steer work already in progress. A steering message needs to reach the relevant workers with my original wording intact. “Delivered” must remain distinct from “understood and applied.”

Their contributions would meet in an integration workspace. That is where the combined change gets built and tested. A queue for each project would check it against the current target branch and current requirements before merging. If the combination fails, that becomes repair work.

Skills and settings would have two scopes: shared harness defaults and project-specific instructions. Workers would receive a recorded snapshot of the instructions they used. A shared MCP gateway would expose permitted tools to both agents and keep a record of their calls.

## What stays on my Mac?

The current design uses Rust for the coordinator, Tokio for asynchronous work, and SQLite for queues, events and recovery state. A background process would keep track of work when I close the terminal, then resume from saved state after a restart. Execution would pause while the Mac is asleep or powered off.

For isolation, I’m looking at [Apple’s open source container project](https://github.com/apple/container), which runs Linux containers in lightweight virtual machines on a Mac. [E2B’s open source runtime](https://github.com/e2b-dev/runtime) is another useful reference, but the requirement here is a sandbox I run locally. The sandbox backend should be replaceable.

Account credentials would stay with a trusted service on the host, backed by Keychain. Workers would receive narrowly scoped access to that service. The broker still needs strict limits on what a worker can ask it to do: keeping a credential out of a file does not by itself prevent misuse.

Local orchestration also doesn’t make Codex or Muse local models. Their model requests still go to their providers. The sandbox, project state and small Laya model would run locally.

## Memory should point back to something

Project setup would build an initial map from source code, documentation, build commands and existing instructions. Human-readable project notes would sit alongside a searchable index. A useful memory should say where it came from and which version of the project it describes.

After a merge, the harness would first mark affected knowledge as stale. It would then use the actual merged code and test evidence to update the notes and indexes, publishing a new knowledge revision together. Active workers would be told about relevant changes without pretending those changes already exist in their older checkouts.

## A small model for the frequent decisions

The coordinator would be a Rust service assisted by **Laya, its local decision model**. Rust would manage queues, worker sessions, delivery and permissions. Laya would recommend how to route messages and classify events. Codex or Muse would handle deeper planning and task decomposition.

I want to try [Laya](https://huggingface.co/convaiinnovations/laya) in five places: choosing recipients for steering messages, ranking context, classifying candidate memories, deciding when background monitoring deserves attention, and classifying failures.

These are proposed uses, each needing its own evaluation. Laya would make bounded recommendations from small inputs. Rules would still enforce permissions. Codex or Muse would handle deeper investigation and draft knowledge updates. Low-confidence or invalid results would fall back to rules or a coding agent.

The attraction is a local model that can help with decisions we make often. Whether it saves time while making good enough decisions is something I need to test, not assume.

## The first useful test is small

One repository. One code mod. Two workers making changes that need to fit together. Then a steering message, a failed test, a restart, and a merge that updates project memory.

I’ll start there, including validating the agents’ login, session and sandbox behavior. If that loop works reliably, we can add concurrency and see where it actually helps. I’ll write about what holds up and what needs to change.

## Projects behind the design

- [Codex](https://github.com/openai/codex) and [Muse Code SDK](https://meta-models.github.io/muse-code-sdk/next/): the coding agents and their programmatic interfaces.
- [Apple container](https://github.com/apple/container) and [E2B runtime](https://github.com/e2b-dev/runtime): sandbox implementations to study.
- [Model Context Protocol](https://modelcontextprotocol.io/): the shared tool interface.
- [Laya](https://huggingface.co/convaiinnovations/laya) and [laya-apple](https://github.com/tc3oliver/laya-apple): the local decision model and a community Apple runtime to evaluate.
[Read this article and all diagram descriptions as Markdown ↗](https://minimumeffort.dev/blog/building-sprowt-harness.md)

## Architecture: text companion

All diagrams describe a proposed system. Local service, isolated worker, saved information and external service are the four box types. Solid arrows carry work or information. Arrows with heads at both ends carry messages and replies in both directions. Dashed arrows carry recommendations. Side-by-side boxes describe separate paths. All components are local unless marked external.

### How a request becomes a change

A Rust coordinator uses Laya’s recommendations to help direct the work. Codex and Muse build in parallel and exchange messages through a shared mailbox. Open a component to see how it works.

**Open your project** (Local service)

Run sprowt in a repository. The harness reads the project’s instructions and connects your terminal to a background process that keeps work running.

- Receives: A repository and your request.
- Produces: A registered project and a place to start or resume work.

**Coordinate the work** (Local service)

Each feature or fix gets a code mod with its own conversation, queue and plan. The Rust coordinator owns scheduling, delivery and permissions. Laya recommends message recipients and helps triage events and failures. Codex or Muse handles deeper planning.

- Receives: Your request, project context and queued messages.
- Produces: A recorded plan and assignments for one or more workers.

**Build in separate workspaces** (Isolated worker)

A worker is a Codex or Muse session with a specific assignment and its own restricted workspace. Workers exchange questions, replies and artifact links through the code mod’s mailbox while keeping separate model conversations.

- Receives: A bounded assignment, context, permissions and teammate messages.
- Produces: Replies, proposed commits, test results and other artifacts.

**Share a mailbox** (Saved information)

The shared MCP gateway exposes messaging tools to Codex and Muse. A mailbox scoped to the code mod retains sender identity and addresses each message to its recipients. Provider adapters deliver messages to the appropriate sessions.

- Receives: Addressed messages from workers and the coordinator.
- Produces: Messages for teammates and artifact references for integration.

**Check and combine the changes** (Local service)

The harness combines the workers’ commits in a separate workspace, checks them together, and queues the result for the project’s target branch.

- Receives: Worker contributions and the latest requirements.
- Produces: A verified change, or repair work for a worker.

**Update what the project knows** (Saved information)

After a merge, project knowledge is checked against the code that actually landed. Future work can use the new facts, while existing workers keep context appropriate to their own checkout.

- Receives: The merged change, its commit and test evidence.
- Produces: Updated project knowledge with traceable sources.

Connections:

- Open your project sends to Coordinate the work: your request.
- Coordinate the work sends to Build in separate workspaces: assignments.
- Build in separate workspaces exchanges messages with Share a mailbox: messages + replies.
- Share a mailbox sends to Check and combine the changes: artifact references.
- Check and combine the changes sends to Update what the project knows: confirmed merge.

The mailbox is available throughout a change. It carries questions, replies and artifact references; source changes remain in Git. Multiple code mods can run at once, each with its own mailbox.

### Open a project and pick up where you left off

The terminal is a way into the harness. The background process owns the work and can outlive the terminal window.

**Find the repository** (Local service)

Identify the project root and check whether the harness has seen it before.

- Receives: The current folder.
- Produces: A project identity and its repository location.

**First time here** (Local service)

Inspect the repository’s structure, existing instructions and development commands. Build a draft of the project’s architecture and conventions.

- Receives: Source files, documentation and repository instructions.
- Produces: An initial project brief, code map and open questions.

**Returning to a project** (Saved information)

Load the project’s settings and recorded work. Reconcile saved sessions with workers that are still running.

- Receives: The registered project identity.
- Produces: Saved code mods, settings and current worker status.

**Connect to the background process** (Local service)

Display the current project state without creating a separate copy of the scheduler or workers in each terminal.

- Receives: New project setup or existing project state.
- Produces: A live view of this project’s work.

**Start or resume a change** (Local service)

Open a conversation for a feature, fix or investigation. Its messages and work remain available after the terminal closes.

- Receives: Your requested change.
- Produces: A durable code mod for the coordinator.

Connections:

- Find the repository sends to First time here: new project.
- Find the repository sends to Returning to a project: known project.
- First time here sends to Connect to the background process: register.
- Returning to a project sends to Connect to the background process: restore.
- Connect to the background process sends to Start or resume a change: ready.

Onboarding records unknowns instead of inventing product intent. Existing instructions are inputs to the setup process.

### Keep several changes moving without losing the thread

The coordinator is a Rust service assisted by Laya. Codex or Muse plans the work; Laya recommends where to send updates. You choose whether a message waits or steers work already underway.

**Queue your messages** (Local service)

Pending messages remain editable. Once delivered, their original content is kept in the audit history; a correction becomes another message.

- Receives: One or more messages for a code mod.
- Produces: An ordered queue and an explicit dispatch choice.

**Plan with Codex or Muse** (Local service)

A coding agent proposes a plan and identifies work that can proceed independently. The Rust coordinator records its requirements revision, checks dependencies and schedules the assignments.

- Receives: The next queued request and current plan.
- Produces: New or revised worker assignments.

**Laya suggests recipients** (Local service)

Send selected messages as an ordered batch. Laya ranks relevant workers from their assignment summaries. Explicit recipients take precedence, and uncertain suggestions fall back to rules or a coding agent.

- Receives: Selected messages and active worker assignments.
- Produces: Suggested recipients for an update.

**The Rust coordinator delivers** (Local service)

The harness checks permissions and the current session and turn before delivering an update through a provider adapter. It tracks pending, accepted and failed delivery. Acceptance is not proof the agent understood it.

- Receives: Assignments or steering suggestions with their requirements revision.
- Produces: Tracked delivery to Codex or Muse.

**Let workers talk** (Saved information)

Codex and Muse exchange addressed questions, findings, replies and artifact links through a mailbox scoped to their code mod. Sender identity is retained. Provider adapters steer an active turn when supported, or queue delivery for the next turn. Each worker keeps its own conversation.

- Receives: Questions, findings, handoffs and artifact references.
- Produces: Messages for teammates and the coordinator.

**Save progress and decide what happens next** (Local service)

Persist the plan and worker state. Known failures use rules; unfamiliar failures can be classified by Laya and investigated by a coding agent.

- Receives: Worker results, delivery status and project events.
- Produces: The next scheduled action and a recoverable checkpoint.

Connections:

- Queue your messages sends to Plan with Codex or Muse: wait for next turn.
- Queue your messages sends to Laya suggests recipients: steer now.
- Plan with Codex or Muse sends to The Rust coordinator delivers: assignments.
- Laya suggests recipients suggests information to The Rust coordinator delivers: routing suggestion.
- The Rust coordinator delivers sends to Let workers talk: worker collaboration.
- Let workers talk sends to Save progress and decide what happens next: progress + results.

Laya supplies bounded recommendations for routing, wake-ups and failure triage. The Rust service owns queues, session lifecycles, delivery and permission checks. Explicit recipients take precedence; uncertain recommendations use rules or a coding agent.

### Give workers a place to work and a way to talk

Codex and Muse work in separate sandboxes and communicate through the same code mod mailbox. Two-way arrows show questions and replies while work is running. The coordinator uses Laya’s help to route updates.

**The coordinator assigns the work** (Local service)

The Rust service schedules assignments planned with Codex or Muse. It selects the code revision, context, skills and permitted tools. Laya helps route steering messages and classify events and failures; rules enforce permissions and delivery.

- Receives: A recorded plan, current requirements and project context.
- Produces: Worker launch specifications and addressed updates.

**Connect Codex** (Local service)

Translate the harness’s start, resume, steer and interrupt operations into Codex’s programmatic interface.

- Receives: A provider-independent assignment.
- Produces: A managed Codex session.

**Connect Muse** (Local service)

Translate the same lifecycle operations into Muse’s programmatic interface.

- Receives: A provider-independent assignment.
- Produces: A managed Muse session.

**Codex works here** (Isolated worker)

Codex edits and runs tools in its own sandbox and Git worktree. It can ask Muse about a contract, answer a question or share a commit through the mailbox’s MCP tools.

- Receives: Selected context, a worktree, permissions and teammate messages.
- Produces: Questions, replies, commit references and test results.

**Muse works here** (Isolated worker)

Muse works on a parallel assignment and exchanges questions, replies and artifact links with Codex through the same mailbox. Its writable checkout and model conversation remain separate.

- Receives: Selected context, a worktree, permissions and teammate messages.
- Produces: Questions, replies, commit references and test results.

**Shared code mod mailbox** (Saved information)

Workers send addressed questions, replies and artifact links through shared MCP tools. The mailbox retains each sender’s identity and is scoped to one code mod. Provider adapters deliver to an active turn when supported, or queue for the next turn. Delivery is tracked separately from whether a message was understood.

- Receives: Messages from either worker or the coordinator.
- Produces: Messages for the intended recipients and announced artifact references.

**Collect results for integration** (Local service)

Resolve commit and test-report references announced through the mailbox. Read the actual artifacts from Git and artifact storage, and normalize provider diagnostics for the coordinator and integration workspace.

- Receives: Artifact references, stored commits and execution evidence.
- Produces: Worker contributions ready to combine and verify.

Connections:

- The coordinator assigns the work sends to Connect Codex: Codex assignment.
- The coordinator assigns the work sends to Connect Muse: Muse assignment.
- Connect Codex sends to Codex works here: launch or resume.
- Connect Muse sends to Muse works here: launch or resume.
- Codex works here exchanges messages with Shared code mod mailbox: messages + replies.
- Muse works here exchanges messages with Shared code mod mailbox: messages + replies.
- Shared code mod mailbox sends to Collect results for integration: artifact references.

The mailbox carries messages and artifact references throughout the work; commits and test reports stay in Git and artifact storage. Apple container VMs and provider lifecycle behavior still need validation. The host broker authenticates provider requests.

### Give workers useful context, then keep it current

Two separate paths: read knowledge for a task on the left; update knowledge after a merge on the right.

**A worker needs context** (Local service)

Begin with the worker’s actual code revision and the latest requirements for its code mod.

- Receives: Task, commit and requirements revision.
- Produces: A scoped context request.

**A change has merged** (Local service)

Observe target-branch changes, including merges made outside the harness. Use the actual merged result, including conflict resolutions.

- Receives: The target branch’s previous and new commit.
- Produces: An update job tied to those commits.

**Find relevant material** (Local service)

Search a code map and text index for a small candidate set. Keep project and branch boundaries explicit.

- Receives: A scoped context request.
- Produces: Candidate snippets with source references.

**Mark affected knowledge stale** (Local service)

Identify knowledge derived from changed files or decisions. Show its freshness so workers do not silently rely on outdated material.

- Receives: The merged diff and knowledge dependencies.
- Produces: Staleness markers and affected records.

**Rank candidates with Laya** (Local service)

Ask the local model which candidates help the assignment. Mandatory project and safety instructions remain included regardless of ranking.

- Receives: Short task and snippet descriptions.
- Produces: A relevance ordering to evaluate and apply.

**Draft knowledge updates** (Local service)

A coding agent writes candidate changes to the project brief, architecture notes and recorded lessons.

- Receives: Merged source, decisions and test evidence.
- Produces: Proposed memory updates with citations.

**Assemble the context** (Local service)

Combine the assignment, required instructions, selected skills and useful evidence into a versioned package.

- Receives: Ranked candidates and mandatory instructions.
- Produces: A context snapshot for the worker.

**Classify candidates with Laya** (Local service)

Classify new memories and flag possible duplication or contradiction for reconciliation. The classifier does not establish that a claim is true.

- Receives: Short candidate memories and relevant existing records.
- Produces: Labels and review suggestions.

**Give it to the worker** (Isolated worker)

The worker receives the package and notices about relevant newer changes. Its checkout is not silently upgraded.

- Receives: A versioned context snapshot.
- Produces: A grounded starting point for the assignment.

**Publish verified knowledge** (Saved information)

Check sources, refresh affected indexes and publish an atomic knowledge revision. Notify active code mods affected by the change.

- Receives: Reconciled memory updates and fresh indexes.
- Produces: Versioned knowledge for future context requests.

Connections:

- A worker needs context sends to Find relevant material: look up.
- Find relevant material sends to Rank candidates with Laya: candidates.
- Rank candidates with Laya suggests information to Assemble the context: ranking.
- Assemble the context sends to Give it to the worker: context package.
- A change has merged sends to Mark affected knowledge stale: changed source.
- Mark affected knowledge stale sends to Draft knowledge updates: evidence.
- Draft knowledge updates sends to Classify candidates with Laya: candidates.
- Classify candidates with Laya suggests information to Publish verified knowledge: review suggestions.

Knowledge is separated by project, with a distinct harness namespace. Every accepted fact has a source and revision. New target-branch facts are not treated as if they already exist in an older worker checkout.

### Share a way of working without erasing project differences

Harness defaults, project instructions and code mod preferences resolve into one explicit configuration for each worker.

**Read settings at three levels** (Local service)

Start with harness defaults, apply project preferences, then task-specific overrides. Keep the source of each setting available for inspection.

- Receives: Settings and skill registries at each scope.
- Produces: A proposed effective configuration.

**Enforce permission limits** (Local service)

Resolve ordinary preferences separately from security restrictions. Lower-level settings cannot increase the permissions set by the harness.

- Receives: The proposed configuration and permission policies.
- Produces: An effective configuration within the allowed limits.

**Select skills for the assignment** (Local service)

Choose relevant instructions through the context service, with Laya helping rank candidates. Use namespaced skills to avoid accidental collisions.

- Receives: Assignment, project conventions and skill descriptions.
- Produces: The skills relevant to this worker.

**Pin the selected versions** (Saved information)

Record the exact skill versions and effective settings used in a run so later edits do not silently alter an active worker’s instructions.

- Receives: Selected skills and effective settings.
- Produces: A reproducible worker configuration.

**Prepare Codex configuration** (Local service)

Materialize the common instructions and supported provider settings for Codex.

- Receives: The pinned snapshot.
- Produces: Codex’s worker configuration.

**Prepare Muse configuration** (Local service)

Materialize the same common instructions and supported provider settings for Muse.

- Receives: The pinned snapshot.
- Produces: Muse’s worker configuration.

Connections:

- Read settings at three levels sends to Enforce permission limits: resolve.
- Enforce permission limits sends to Select skills for the assignment: allowed configuration.
- Select skills for the assignment sends to Pin the selected versions: selected skills.
- Pin the selected versions sends to Prepare Codex configuration: adapt.
- Pin the selected versions sends to Prepare Muse configuration: adapt.

A skill is an instruction package, not a permission grant. A project can tighten the harness’s limits; it cannot grant a worker access the harness has forbidden.

### Use a small local model for small, frequent decisions

Laya supports all five uses: message steering, context ranking, memory classification, event monitoring and failure triage.

**Ask a bounded question** (Local service)

Examples: which worker needs this message; which snippet is relevant; what kind of memory is this; does this event need attention; what kind of failure occurred?

- Receives: Selected text and a small set of possible answers.
- Produces: A named decision request.

**Check the request** (Local service)

Validate the question shape and keep the input within the chosen checkpoint’s limits. Do not send whole repositories or unrestricted conversation histories.

- Receives: A decision request.
- Produces: A bounded model input, or a fallback if unsupported.

**Run Laya locally** (Local service)

Share a loaded model across code mods through a private local interface. The service receives selected input and has no provider credentials.

- Receives: A bounded question and candidate answers.
- Produces: A typed choice, score or yes/no probability.

**Check the result** (Local service)

Check the returned shape and apply thresholds evaluated for this use case. Record model and schema versions for later comparison.

- Receives: The model result and per-task policy.
- Produces: A decision about whether the suggestion is usable.

**Return a usable suggestion** (Local service)

For a validated use case, return the suggestion to the requesting component. In shadow mode, record it while the normal path makes the decision.

- Receives: An eligible model prediction.
- Produces: A recommendation and an audit entry.

**Use the fallback** (Local service)

Uncertain, unsupported, timed-out or failed requests go to explicit rules or a Codex/Muse coordinator.

- Receives: An unsuitable result or a runtime failure.
- Produces: A fallback decision and an audit entry.

**Compare with the outcome** (Saved information)

Compare predictions with reviewed outcomes. Use held-out examples to assess accuracy and confidence before enabling more automatic behavior.

- Receives: Predictions and reviewed results.
- Produces: Evaluation data and updated decision policies.

Connections:

- Ask a bounded question sends to Check the request: request.
- Check the request sends to Run Laya locally: validated input.
- Run Laya locally suggests information to Check the result: prediction.
- Check the result suggests information to Return a usable suggestion: eligible.
- Check the result sends to Use the fallback: needs another path.
- Return a usable suggestion sends to Compare with the outcome: record.
- Use the fallback sends to Compare with the outcome: record.

Each use gets its own evaluation set and thresholds. We start by recording suggestions in shadow mode. Model confidence alone never grants permissions or approves a merge.

### Give both agents one controlled way to use tools

MCP is the protocol coding agents use to call tools. The gateway gives Codex and Muse the same catalog and enforces the same access rules.

**A worker requests a tool** (Isolated worker)

The agent requests a named tool with arguments and a short-lived capability identifying its project, code mod and worker.

- Receives: A tool name, arguments and worker capability.
- Produces: A request for the gateway.

**Check identity and scope** (Local service)

Validate the capability and the specific resources in the arguments. Reject calls that exceed the worker’s assignment scope.

- Receives: The request and harness policy.
- Produces: An authorized call or an explicit denial.

**Call a harness tool** (Local service)

Internal tools route worker messages, share artifact references and read project knowledge through the harness’s own services.

- Receives: An authorized internal tool call.
- Produces: A scoped team or context result.

**Call a connected tool** (Local service)

Route to an isolated local MCP server or an approved remote service. The host supplies any upstream authentication.

- Receives: An authorized integration call.
- Produces: The connected service’s result.

**Record a redacted audit event** (Saved information)

Capture which worker called which tool and its outcome, without recording credentials in ordinary logs.

- Receives: Call identity, safe arguments and result metadata.
- Produces: An audit record.

**Return the result to the worker** (Isolated worker)

Deliver the response in the form the provider expects. Tool output remains untrusted input to the agent.

- Receives: Tool output or an error.
- Produces: A result for the requesting coding session.

Connections:

- A worker requests a tool sends to Check identity and scope: tool call.
- Check identity and scope sends to Call a harness tool: harness tool.
- Check identity and scope sends to Call a connected tool: integration.
- Call a harness tool sends to Record a redacted audit event: result.
- Call a connected tool sends to Record a redacted audit event: result.
- Record a redacted audit event sends to Return the result to the worker: deliver.

A tool being visible is not permission to call it. The gateway checks arguments too. Mutable browser, database and workspace sessions are separated by worker.

### Keep real credentials outside worker workspaces

Workers receive narrow, temporary capabilities. A trusted host broker authenticates provider requests without copying account credentials into the sandbox.

**The worker asks to call its provider** (Isolated worker)

The coding session sends a request using a disposable capability. That capability is tied to a project, code mod, worker and allowed destination.

- Receives: A model request and scoped capability.
- Produces: A request to the host broker.

**Check what this worker may do** (Local service)

Validate the capability, expiry and route before any account credential is added. Reject requests outside the allowed scope.

- Receives: The worker request and deterministic policy.
- Produces: An approved request or denial.

**Keep the account credential here** (Saved information)

A normal provider login on the host supplies the real credential. It remains in trusted host storage and services, separate from the worker’s files.

- Receives: Credentials from the host login flow.
- Produces: Authentication available only to trusted host services.

**Authenticate the approved request** (Local service)

The broker adds the appropriate upstream authentication and forwards only the allowed request to the provider.

- Receives: An approved worker request and host credential.
- Produces: An authenticated upstream request.

**The provider runs its model** (External service)

The CLI’s model inference runs with the provider. Local worker isolation does not make provider inference local.

- Receives: The authenticated inference request.
- Produces: A model response.

**Return the model response** (Local service)

Deliver the result and record safe request metadata. Avoid leaking credentials through logs, redirects or error handling.

- Receives: The upstream response.
- Produces: A response for the coding session.

Connections:

- The worker asks to call its provider sends to Check what this worker may do: request.
- Check what this worker may do sends to Authenticate the approved request: approved.
- Keep the account credential here sends to Authenticate the approved request: host credential.
- Authenticate the approved request sends to The provider runs its model: authenticated call.
- The provider runs its model sends to Return the model response: response.

The sandbox permits approved network routes only. Capabilities expire or can be revoked. MCP authentication uses the same host credential boundary. Each provider’s full login and refresh flow still needs validation.

### Make parallel changes work together

Workers can finish in parallel. Updates to a project’s target branch pass through one merge queue so each change is checked against what landed before it.

**Worker A contribution** (Isolated worker)

Collect a worker’s proposed commits and relevant test results without changing another worker’s checkout.

- Receives: Completed worker work.
- Produces: A contribution for integration.

**Worker B contribution** (Isolated worker)

Collect the parallel contribution from another Codex or Muse worker.

- Receives: Completed worker work.
- Produces: A contribution for integration.

**Combine in a fresh workspace** (Local service)

Integrate the contributions in the code mod’s own sandbox. Run the project’s checks on the combined result and assign repairs when needed.

- Receives: Worker commits and current requirements.
- Produces: A combined candidate with verification evidence.

**Wait for the project merge queue** (Saved information)

Queue ready code mods for the same project. Work on other projects can continue independently.

- Receives: A ready integration candidate.
- Produces: A turn to update the target branch.

**Check against the latest target** (Local service)

Update the candidate against the current target branch. Re-run relevant checks and confirm the result meets the latest requirements revision.

- Receives: Candidate, latest target commit and current requirements.
- Produces: A verified candidate or repair work.

**Apply the approval policy** (Local service)

Show the diff and evidence required by the configured policy. Only authorized changes proceed to the target update.

- Receives: The verified candidate and approval requirements.
- Produces: Authorization to integrate this candidate.

**Update the target and publish the event** (Local service)

Apply the change only if the target still has the expected commit. Otherwise refresh and verify again. Emit the actual before and after commits after success.

- Receives: An authorized candidate and expected target commit.
- Produces: A merged change and a memory-update event.

Connections:

- Worker A contribution sends to Combine in a fresh workspace: contribution A.
- Worker B contribution sends to Combine in a fresh workspace: contribution B.
- Combine in a fresh workspace sends to Wait for the project merge queue: checks pass.
- Wait for the project merge queue sends to Check against the latest target: next candidate.
- Check against the latest target sends to Apply the approval policy: verified.
- Apply the approval policy sends to Update the target and publish the event: authorized.

Failed checks create repair assignments. A changed target commit returns the item to verification. Approval follows the project’s configured policy; Laya cannot approve a merge.

### Make work recoverable and decisions inspectable

Save the state needed to resume work, the evidence needed to review it, and the measurements needed to tell whether the harness is helping.

**Receive events from every component** (Local service)

Use stable identifiers to connect a message, assignment, tool call, result and merge without mixing different projects.

- Receives: State changes and execution evidence.
- Produces: Identified events and artifacts.

**Remove sensitive data before storage** (Local service)

Store useful diagnostics while keeping credentials out of ordinary logs. Limit collection to evidence needed for operation and review.

- Receives: Events and candidate artifacts.
- Produces: Records appropriate for their storage scope.

**Save operational state** (Saved information)

Persist conversations, queues, assignments, delivery events, checkpoints and decision records so they can be recovered consistently.

- Receives: Durable runtime records.
- Produces: Recoverable work state.

**Save knowledge and artifacts** (Saved information)

Keep curated documentation and skills in versioned Markdown. Store patches, test reports and context snapshots as referenced artifacts.

- Receives: Knowledge revisions and execution evidence.
- Produces: Versioned documents and reviewable artifacts.

**Resume safely after a restart** (Local service)

Check which workers still exist, restore pending jobs and avoid replaying completed side effects blindly.

- Receives: Checkpoints and live worker status.
- Produces: A reconciled scheduler state.

**See what happened and what helped** (Local service)

Show current progress, trace failures and compare Laya suggestions with reviewed outcomes. Measure latency and resource use alongside correctness.

- Receives: Events, artifacts and outcomes.
- Produces: User-facing progress and improvement evidence.

Connections:

- Receive events from every component sends to Remove sensitive data before storage: record safely.
- Remove sensitive data before storage sends to Save operational state: runtime state.
- Remove sensitive data before storage sends to Save knowledge and artifacts: knowledge + evidence.
- Save operational state sends to Resume safely after a restart: checkpoints.
- Save knowledge and artifacts sends to See what happened and what helped: evidence.

Credentials are held separately in Keychain. Logs and artifacts need explicit redaction and retention rules; recording more data is not automatically more useful.