By Thales (Juste Gnimavo) — CEO & Founder, ZeroSuite, Inc.
Client note: Where a client project is referenced, it appears under the pseudonym KASSIA. The company's real name and domain are withheld at the client's request while their public website is being finished.
The question I get more than any other is some version of: "How do I get the best out of Claude?"
People asking it are almost always looking for a better prompt. A magic phrasing. A system prompt that unlocks a hidden tier of the model. And I understand the instinct, but it is the wrong frame, and chasing it is why most people plateau at "impressive autocomplete."
Here is the real answer, and it took me sixteen months and seven production products to arrive at it: the best of Claude is not one genius in one chat. It is three specialized Claude surfaces, operated as a team, on a single shared thread of state that survives the fact that none of them remember anything.
That sentence has two halves, and both matter. The first half — the trio — is about using the right surface for the right job. The second half — the shared, validated thread — is about the problem nobody warns you about: the three surfaces share no memory, and without a deliberate fix, every handoff between them leaks. The fix is a small open-source protocol I built called CASP. This article is how the two halves fit together into one operating system.
The operating system in one picture: three Claude surfaces, each a sealed context with no memory of the others, connected by one validated state thread. Strategy flows to design to implementation; every handoff reads and writes the same CASP files — and casp check blocks the push the moment that state stops matching git.
The trio: three surfaces, three jobs
Claude is not one product you talk to. It is at least three distinct operational contexts, and the people who get the most out of it are the ones who stopped treating them as interchangeable.
Claude Web (claude.ai, the chat) is the strategist and co-founder. This is where I hold long-form, multi-day strategic conversations: product positioning, market reasoning, the SPEC documents, the copywriting, the architecture arbitration. Web Claude holds a long argument across many turns, references back to things I said an hour ago, and — when I have set it up correctly — pushes back when my framing drifts. I have had it quote my own earlier message back at me and refuse to validate a pivot until I produced a market signal. That is a strategic advisor, not a search box.
Claude Design (claude.ai/design) is the lead designer. It owns the entire visual and UX system end to end — tokens, a typed component library, clickable UI kits, the design language for the AI features inside the product. Not mockups: a version-controlled, production-grade design system produced from a brief. I wrote a whole article on just this surface, because it is the most underrated of the three: Claude Design Is the Most Underrated Member of My AI Team.
Claude Code (the CLI) is the senior engineer with a team of sub-agents. Structured tickets, parallel Git branches, dependency graphs, multi-agent audit loops, regression-safe commits. This is where decisions become shipped code. The full engineering system around this surface — the CLAUDE.md constitution, the session architecture, the double-audit loop, the authority to say no — is its own long article: The Complete, Unfiltered Workflow I Use to Get Claude to Build Production-Grade Software.
Each surface has its own strengths, its own input format, and its own quality bar. Running Web Claude well is not the same skill as running Claude Code well. Operating the trio is the skill of a CEO directing three specialists — a strategist, a designer, an engineer — not the skill of a hobbyist asking a bot to write code. That part most serious builders eventually figure out.
Here is the part they do not.
The problem nobody warns you about: the trio has amnesia
The three surfaces share no memory. None.
The strategic conversation I had with Web Claude on Monday — the one that set the entire positioning of a feature — does not exist for Claude Code on Tuesday. The design system Claude Design produced lives in its workspace; the engineering session that has to port it starts blind to how it was reasoned. And Claude Code itself has no persistence across sessions: every session starts from zero context, by design, because there is no memory between them.
So what you actually have, when you operate the trio, is three brilliant specialists locked in three separate rooms, each with total amnesia about what happens in the other rooms — and about what they themselves did yesterday. The strategist forgets. The designer forgets. The engineer forgets. Every handoff between them is a doorway where context falls on the floor.
This is the real bottleneck to getting the best out of Claude at scale. It is not model quality — the models are extraordinary. It is that the more capable each surface gets, the more devastating the amnesia becomes. The new models run for hours, even days, executing phase after phase. A surface that does more between your checkpoints is a surface whose recorded state can quietly stop matching reality across a longer and longer gap. Capability makes the memory problem worse, not better.
People paper over this with boards, cards, Notion pages, a STATE.md file they update by hand. None of it works, for two reasons. First, it is manual, so it rots — you stop updating it the day you are busy, which is every day. Second, and worse: the agent cannot reliably read it, and it cannot prove it is true. A state file that says "next: build the camera feature" when the camera shipped last week does not just fail to help — it makes your agent confidently wrong. It starts work that already exists. You lose an afternoon undoing it. A stale state file is the single most expensive failure mode in AI-assisted development, because you do not catch it until the duplicate work is done.
CASP: the memory the trio doesn't have — and that can't lie
So I built the missing layer and open-sourced it: CASP — the Coding-Agent State Protocol (npx @justethales/casp · casp.sh · MIT, zero telemetry, no SaaS, nothing leaves your machine).
CASP is the shared, validated thread that the three Claude surfaces do not have on their own. It is deliberately tiny — three plain files an agent can read on the first line of any session, scaffolded into a casp/ directory by casp init:
state.json— the machine-readable source of truth: current phase, the exact next-prompt to run, phases shipped, migrations applied, last commit, last session id. This is what any of the three surfaces reads to know where the project actually stands.now.md— the one-screen "where am I right now," for humans. Open it, get the thread back in five seconds.roadmap.md— the Next-3 to ship, in order, plus a phase scoreboard.
That alone would just be a tidier STATE.md. The thing that makes CASP matter is one verb: casp check. Everyone stores context — boards, memory tools, notes. CASP validates it. The check reads your stored state and verifies it against git ground-truth: a next_prompt that points at a phase already shipped, a last_commit that is not in history, a migrations list that disagrees with the migrations directory — all caught, deterministically, with a hard pass/fail. Clean exits zero. Drift exits non-zero and blocks the push. Drop it in CI and a lying state file can never reach your remote.
yaml# .github/workflows/ci.yml — drift can't merge
jobs:
state-check:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with: { fetch-depth: 0 }
- run: npx @justethales/casp check
casp check on a drifted state (top) versus a clean one (bottom). It validates the stored state against git ground-truth and returns a hard pass/fail — so the shared thread the three surfaces rely on can never quietly start lying.
This is the property that makes it work as shared memory for the trio: the thread is not just shared, it is provably true. Memory tools store and recall with fuzzy similarity; CASP runs a synchronous, deterministic check against git and stops you when the state is lying. Shared memory that can itself drift is worthless — you are back to confidently wrong, one level up. Shared memory that is gated against ground-truth is the thing you can actually build a multi-surface workflow on. (CASP is not an AI memory layer in the Mem0 / Letta sense — those remember who you are; CASP tracks where the project stands and proves it. Different artifact, different failure prevented. I wrote the dedicated piece here: CASP: the small CLI that fixed my AI workflow.)
How the trio runs on one CASP thread — a concrete day
Here is what a real day looks like when the three surfaces and the state layer operate as one system. This is not a diagram of an ideal; it is the loop I actually run.
Strategy, in Web Claude. I open a long-form conversation to decide what ships next and why. We argue the positioning, weigh the trade-offs, freeze the decision. The output is not code — it is a frozen spec and a clear next move. That decision lands in the project as the next phase in roadmap.md and a session prompt drafted from the canonical template (casp new prompt — the templates are gates, not suggestions, so every prompt is the same shape).
Design, in Claude Design. If the phase has a surface, Claude Design produces or extends the system for it — the tokens, the component, the UI kit screen — and hands back a production-grade artifact: typed contracts and a pixel-accurate reference. That artifact is the contract the engineering surface will consume. The design decision is now written down, not trapped in a workspace nobody else can read.
Engineering, in Claude Code. The session opens with one command: casp next. Claude Code reads state.json on line one, knows the exact phase and the exact next-prompt — no re-discovery, no "remind me where we were" — and executes. It ports the design artifact against its contract, runs the work in structured phases, and triggers the independent audit loop. At the end, the session writes its own session log, drafts the next session's prompt, and bumps the state — then casp check validates the whole thing against git before anything is pushed. Drift is impossible to ship.
Notice what just happened. The strategist's decision reached the engineer without either of them sharing a context window. The designer's artifact reached the porter as an explicit contract, not a vague "make it look like the mockup." And tomorrow's session — a different blank Claude Code instance — will open state.json and know precisely where the project stands, because the project now remembers itself, in a form that is machine-readable and proven true. The amnesia is still there. CASP just made it stop mattering.
That is the whole trick. You do not fix the memory of any single surface. You give the three surfaces one external thread that does not lie, and the handoffs stop leaking.
How to start — this week
You do not need seven products to run this. You need the two halves.
Half one — operate the trio, stop hunting for the magic prompt. For your next real piece of work, deliberately split it across the three surfaces. Do the strategy and the spec in a long Web Claude conversation, and give it permission to push back. Do the design system — tokens first, then components with contracts — in Claude Design before any production code (the Design article is the playbook). Do the implementation in Claude Code with structured phases and at least one independent audit session. Three surfaces, three jobs, one director: you.
Half two — give them one validated thread. npx @justethales/casp init in your most active repo. Fill state.json honestly once. End your next session by letting the agent draft the next session's prompt and bump the state. Run casp check before you push — and put it in CI the same week. From that point on, every surface opens each session knowing exactly where the project stands, and a lying state file can never reach your remote.
The mindset shift is the whole thing: stop trying to extract more from one Claude. Start operating three, and give them a memory that can't drift. The leverage is not in the prompt. It is in the orchestration.
The bigger picture
I build from Abidjan, with a Claude Max subscription, as the only engineer on seven production products. None of that is possible by getting clever with a single chat window. It is possible because I stopped asking "how do I get the best out of Claude" and started asking "how do I operate a virtual team of Claude specialists so that the project never forgets itself."
The model holds the context. The trio does the work — strategy, design, engineering, each on the surface built for it. And CASP proves the state is true, so three surfaces with no shared memory can still behave like one team that never loses the thread.
That is how you get the best out of Claude. Not a better prompt. A better operating system.
Read next:
- Claude Design Is the Most Underrated Member of My AI Team — the deep dive on the design surface and the six-step process.
- The Complete, Unfiltered Workflow I Use to Get Claude to Build Production-Grade Software — the full seven-pillar engineering system around Claude Code.
- CASP: the small CLI that fixed my AI workflow — the dedicated story of the state layer. Source on GitHub, npx @justethales/casp init.
One founder. Three Claude surfaces. One validated thread. Seven products.