Inside SHARP Agent Protocol v2: a 22-kilobyte prompt that runs agents like an engineering team
SHARP Agent Protocol v2 is a 488-line instruction set that turns one language model into a managed engineering team: exactly one task per fresh subagent, adversarial tests written before any code, independent verification, and durable memory files that survive context loss. What it does, how to use it, and where its claims outrun the evidence.
The prompts section of this site gained a new entry today: the LLM Sharp Reasoning Prompt, formally titled SHARP Agent Protocol v2 - Multi-Agent Execution, Adversarial Verification and Memory Context Boost. At 488 lines and about 22 kilobytes, it is not a prompt you paste in to get a better email. It is an operating manual that tries to turn one language model into a managed engineering team: a manager that plans, fresh subagents that each do exactly one task, an adversarial tester that writes failure cases before any code exists, and a set of durable memory files that outlive the conversation. I read the whole text closely. This entry is my map of what it does, the ideas worth borrowing, and the places where its promises outrun what a prompt can actually guarantee.
The short version
SHARP is a system-prompt style protocol in three parts. Part I defines an adaptive execution loop - triage, plan, ideate, test-spec, work, verify, manage - in which a manager agent delegates exactly one task per fresh subagent and then independently verifies the result against explicit acceptance criteria. Part II is a memory discipline: durable files with default names like AGENTS.md, TASKS.md, DECISIONS.md, HANDOFF.md and VERIFICATION.md, a retrieval hierarchy, checkpointing, and a mandatory recovery procedure after context loss. Part III wires everything into one loop with a strict final-report format (Done, Verified, Not verified, Risks, Resume state). Its core claims - plans are not execution, implementation is not proof, conversation history is not memory - are sound engineering culture compressed into instructions. The costs are real: heavy token spend on ceremony, assumptions about platform features many setups lack, and no published evaluation, so the benefits are argued, not measured. The full text is published verbatim in the prompts section, linked below.
What the prompt actually is
SHARP arrives as a single block of instructions meant to be installed as a system prompt or standing instruction set for a coding or engineering agent. It opens with a mission statement - operate as a disciplined, self-correcting engineering agent - and a list of seven core principles that read like a code review culture doc: plans are not execution; implementation is not proof of correctness; conversation history is not durable memory; summaries are not ground truth; subagents are contributors, not authorities; a task is not complete until its mandatory acceptance criteria are verified; and never claim capabilities, actions, test results, or success that you cannot substantiate. The body is nineteen numbered sections organized into three parts, ending with a final enforcement rule: never fabricate progress. The text names no author and carries no provenance beyond the v2 in its title, which at least suggests iteration. I make no claims about where it came from; what follows is an analysis of the text itself, which is published verbatim on this site.
Part I: an engineering loop, not a chat
The first part defines seven phases. TRIAGE sizes the task and picks one of three rigor levels - trivial, standard, or complex - with an explicit warning that triage chooses the amount of work, not permission to skip mandatory checks. PLAN has the manager write a short strategy, three to six concrete tasks tagged by difficulty, acceptance criteria for each, and the evidence that will prove success. IDEATE sends the problem to a fresh subagent that has not seen the current work, requiring at least three genuinely distinct approaches with failure modes, and forbids implementation code at this stage. TEST-SPEC is the unusual one: before implementation begins, a fresh adversarial subagent writes tests designed to discover how the proposed solution could fail - boundary inputs, races, injection risks, regressions - and those tests are preserved for the verification phase. WORK hands exactly one task to each fresh implementation subagent with a disciplined brief, forbids scope creep, and requires a self-attack pass naming at least three plausible failure modes. VERIFY puts the manager back in charge: it must actually run the implementation and the adversarial tests, and the evidence rules are blunt - never claim a test passed unless it ran and passed, never hide skipped checks, and a failed mandatory criterion overrides every previous claim of completion. MANAGE closes the loop with a traffic-light classification (green, yellow, red) and a recovery procedure that backtracks, races alternatives, or switches approaches rather than patching indefinitely.
Part II: memory as a first-class component
The second part treats context-window exhaustion, session restarts and compaction as expected operating conditions, not edge cases. Its central rule: critical knowledge must be recoverable from durable state, not from conversation history. It prescribes five default files - AGENTS.md for persistent project instructions, TASKS.md for execution state, DECISIONS.md for decision history with rejected alternatives, HANDOFF.md as a resume point, and VERIFICATION.md as an evidence log of checks actually executed - while stressing the names are defaults and existing project records should be reused. Around those files it builds a retrieval hierarchy (current instructions and repository docs outrank memory, memory outranks conversation summaries), rules for updating records at meaningful milestones, context-budget management that saves recovery checkpoints before a likely compaction, and a strict assumption that every fresh subagent starts with no implicit memory, so handoff briefs must be complete. Two sections stand out. CONTEXT RECOVERY is a mandatory nine-step procedure after any interruption: re-read the records, inspect the actual repository state, check whether previously claimed changes really exist, and resume from the earliest unresolved dependency - never trusting a summary that contradicts observed state. And the RESUMABILITY TEST asks, for any substantial unfinished work, whether a fresh agent could continue from the durable records alone; if the records cannot answer what the user wants, what is verified, and what happens next, they must be improved before the session ends.
Part III: one loop, one report format
The final part compresses everything into a single pipeline - triage to plan to ideate to test-spec to work to verify to manage to memory update to the next task - with memory retrieval running throughout. The closing section defines a final-response format I would happily see adopted everywhere: report what is done, what was verified with observed results, what was not verified, the risks, and the resume state for unfinished work. It also bans claiming that memory was saved unless the write actually succeeded, and claiming a task can resume unless the records exist. The last line is the whole philosophy in one sentence: actual implementation and executed verification establish truth.
What it gets right
The protocol reads like a list of observed agent failure modes with a countermeasure attached to each. Hallucinated success gets the evidence rules. Scope creep gets the exactly-one-task rule. Lost context gets the memory files and the recovery procedure. Sycophantic subagents get the line that a subagent's code and claims are untrusted until checked. The fresh-context-per-task design mirrors how serious orchestration frameworks already behave, and writing adversarial tests before implementation is red-team thinking applied at the cheapest possible moment. I also like the honesty constraints that most prompts skip: disclose when a required capability is unavailable, never simulate compliance, and never downgrade a task to dodge required checks. Whether or not you adopt the whole protocol, the VERIFICATION.md habit - a running log of commands executed and outcomes observed - is worth stealing on its own.
How to use it
Paste the full text as the system prompt or standing instructions of an agent platform that genuinely supports subagents and persistent files; that is the audience the protocol assumes. On a lighter setup, the triage section gives you permission to run a stripped version: trivial tasks get direct execution with proportionate checks, and the full multi-agent ceremony only triggers on complex work. Adapt the memory filenames to whatever your project already uses rather than creating parallel documents - the text explicitly allows this. Expect token usage to rise sharply on hard tasks, since ideation, adversarial test-writing and independent verification are all extra model calls by design. And keep the final-report format even if you keep nothing else; it forces the difference between done, verified and assumed into the open.
Honest limits
Several, and the prompt itself would probably insist I list them. First, there is no published evaluation: nothing in the text or elsewhere demonstrates that agents following SHARP produce measurably fewer defects than simpler instruction sets, so every benefit here is argued from structure, not evidence. Second, the protocol assumes platform features - spawnable fresh subagents, durable files, retrieval, context-usage telemetry - that many deployments simply do not have, and a model on a lesser platform may simulate the ceremony rather than skip it honestly. Third, 22 kilobytes of instructions is itself a context tax that competes with the very budget the memory sections try to protect. Fourth, a prompt constrains behavior; it cannot guarantee it. A model can still write "all tests passed" for tests that never ran - the protocol can forbid the lie, but it cannot prevent it, which is why the manager-side verification habit matters more than any single rule. Finally, the ceremony has a cost on small tasks even with triage, and teams that already run disciplined CI and code review will find parts of it redundant with tooling that enforces the same rules mechanically rather than by asking nicely.
Where to read the full text
The complete protocol is published verbatim - all 488 lines - in the prompts section of this site as the LLM Sharp Reasoning Prompt, with the surrounding page in six languages. If you run multi-agent coding workflows, it is worth twenty minutes of reading even if you only keep three ideas: one task per fresh subagent, adversarial tests before code, and a verification log that records what actually ran.