Everything Is a Prompt: Context Engineering with COSAW
A partner at the company recently mentioned that "context engineering" is the current trend — the practice that supposedly replaces prompt engineering. The honest answer is that everything is prompts, and context engineering is what you call it when you stop leaving the model’s context to chance. This article is about COSAW — Context-Optimized Sub-Agent Workflow — the system Frao built to engineer the context a model reasons over, phase by phase, agent by agent.
The problem: context decay
A model’s output quality is a function of the context it reasons over, not the cleverness of the instruction you type. In a single long session that context degrades. The conversation accumulates decisions, re-reads, and digressions; after roughly 50 turns the model starts forgetting earlier constraints, contradicting its own choices, and paying to re-scan a bloated window. This is context decay, and it is the real tax on LLM-assisted development.
The naive response is to write a better prompt. COSAW’s response is to change what the model sees.
The unit of work: one phase, one agent, one context
COSAW decomposes a goal into phases before any code is written. The sequence is deliberate: analysis → architecture → design → implementation plan → phase dependency graph. Each stage produces a durable artifact — an ANALYSIS.md, an ARCHITECTURE.md, an IMPLEMENTATION-PLAN.md, a phase DAG — and each phase is scoped to fit cleanly in a single context window.
Every phase becomes a dedicated task with a self-contained brief. The brief is the contract: current state, what to build, required skills, step-by-step instructions, guardrails, and a completion protocol. It is deliberately condensed — the minimum context that phase needs, nothing more.
Each task runs in total isolation:
- its own Claude instance, started fresh
- its own git worktree on its own branch from
dev - its own tmux session
- its own container
No phase’s context bleeds into another. A thirty-phase build is thirty fresh, focused reasoners, not one exhausted one.
tmux is the IPC substrate — and the trick is self-injection
The oversight session never shares a context with its agents. It orchestrates them through tmux, a terminal multiplexer old enough to predate all of this and unaware that it is now an inter-process bus.
How instructions get in — and who does what:
- The main session places the brief. It writes the brief to a file, loads it into the tmux buffer, and pastes it into the agent’s composer as raw bytes —
load-bufferthenpaste-buffer. Nothing is interpreted along the way. At this point the text is sitting in the agent’s input box. It has not reached the model. - The agent injects the brief into itself. The agent presses Enter — a separate
send-keys Enter, never combined with the paste — and that submit is what moves the text from the input box into its own reasoning context.
That is the self-injection trick, and the division of labor is the whole point. Both sides run the same MCP binary, but in different roles: the main session runs mcp mode with the launch tools, the agent runs agent mode with the report tools. Neither can call the other’s model — there is no channel for it. The only door into an agent’s context is the agent’s own composer, and only the agent can open it. The orchestrator’s job ends at placement. The agent does the injecting, into itself, from the inside.
- Progress is read the way an operator reads it:
capture-panegrabs the agent’s screen. - Completion is a machine-parseable signal:
===PHASE_COMPLETE===, staged to git by the agent before it stops.
cosaw_bus_send
cosaw_task_status
· paste-buffer → brief in composer
· send-keys Enter (separate)
· capture-pane → progress
· implements
· git add -A
· echo ===PHASE_COMPLETE===
frao-cosaw-mcp wraps these primitives in the Model Context Protocol. The oversight agent gains first-class tools — cosaw_task_launch, cosaw_task_status, cosaw_bus_send — that compile down to tmux operations, but with validation, state, and an audit trail. Under the hood it is still terminal multiplexing; at the interface it is a typed control plane.
A shared filesystem bus (.cosaw/<workflow>/bus/, flock-protected, append-only) gives the otherwise-isolated agents a way to talk: reports back to the main session, messages between sessions. True inter-process communication between agents that never share a model context.
Containerization is the portability bet
The whole runtime — phase-orchestrator, cosaw-mcp, Claude, tmux — bakes into a single image. Task agents are containers. Two consequences follow.
- An agent is a reproducible unit. The same image, the same mounts, the same socket layout runs anywhere Docker does.
- The container boundary is the seam where multi-host deployment happens. Move a phase to another host and the orchestrator reaches it over the same REST surface, the same bus, the same
.cosaw/store.
Frao currently runs one host. The workflow does not assume one — that is the entire point of the container.
COSAW as a service: the app-engine
The strongest proof the workflow is sound is that it outgrew its development-process role and became a runtime. Frao App Engine is an agent-driven PaaS: a user types "build me a web clock", and the app-engine launches a full COSAW workflow through the phase-orchestrator. The orchestrator drives frao-cosaw-mcp; cosaw-mcp launches the main session and task agents; the agents write the app in their isolated workspaces; the workflow reaches merged; the app builds, deploys, and goes live.
The same pipeline — analysis, architecture, design, plan, phases — that once organized internal engineering now executes product work on demand. The workflow is the product.
What it buys
| What | Effect |
|---|---|
| Reasoning quality | Each phase reasons from a fresh, tight context — no decay across the build |
| Cost | Condensed briefs and fresh windows; default reasoning tier ≈35× cheaper than Claude-class |
| Observability | Every agent is a tmux pane; orchestrator dashboard; machine-parseable completion |
| Auditability | .cosaw/<workflow>/ is a committed, durable record of every phase |
| Portability | Containerized agents deploy to any Docker host — the container is the seam |
| Human gates | Greenlight between analysis and execution; per-phase review before merge |
Each task also runs an automated expert review at three checkpoints — an architecture review before implementation, a code review during, a final second opinion before completion — and cosaw-mcp monitors every session’s context size, compacting and migrating before a window can degrade the work. The whole point is that nothing a model reasons over is left to accumulate by accident.
Everything is prompts
Context engineering is not an alternative to prompting. It is prompting done properly: deciding, deliberately, what content the model reasons over. COSAW writes the prompt the model actually sees — one isolated phase at a time, with the minimum context each phase needs. We did not discover a new paradigm. We stopped holding the door open for context decay.
The reasoning tier we default to runs at $0.14/M input; the review tier at $0.435/M. Context engineering pays for itself long before the tokens do.
For the complete breakdown — every MCP tool, the bus, the orchestrator’s launch modes, the Docker wiring — the specification is in COSAW Under the Hood.