The core of the Tripartite methodology is the absolute segregation of responsibilities beneath a human executive, coordinated through a shared, asynchronous file system rather than conversational history.
To prevent hallucinations and LLM confirmation bias, no single agent holds the entire pipeline. The system enforces strict constraints via the following roles:
Role: The ultimate source of strategic intent and business reality. Defines the high-level goals (e.g., "We need a production-ready kinase selectivity model"). Directly engages primarily with Agent 3 (Director) and Agent 2 (Reviewer/Scientist), offering scientific critiques and feedback.
Constraint: The Human does not usually write code or format JSON manifests. They issue natural-language directives, constraints, and critiques. They may occasionally intervene directly with Agent 1 (Builder) to forcefully unstick a technical failure.
Role: Operates entirely outside the turn-by-turn conversational loop, typically as a CLI-based agent acting as the direct proxy for the Human Overlord.
Constraint: The Director does not write project code. It monitors the file system, reads logs asynchronously, and injects "business reality" from the Human via dedicated observation files (e.g., OBSERVATIONS.md) into the active loops.
Role: Audits the Builder's code for data leakage and methodological errors, interprets the observations, declares verdicts (Supported / Overstated / Refuted), and sets the pipeline priorities.
Constraint: The Reviewer is strictly forbidden from writing core project code or launching jobs. However, it maintains exclusive ownership over the Reporting Layer (e.g., HTML presentations). This ensures the final output reflects audited reality, not the Builder's optimism.
Role: Writes project code, executes experiments, and manages the computational queue.
Constraint: The Builder is strictly forbidden from drawing scientific conclusions. It outputs empirical observations (e.g., "Arm A scored 0.65"). It does not evaluate its own success. It is the sole owner of the core codebase to prevent version-control collisions.
A major challenge in autonomous LLM workflows is context window exhaustion. After dozens of cycles of experimentation, log reading, and reporting, an agent's context fills up. This degrades reasoning performance, drastically increases token costs, and eventually leads to hard API failures.
To counter this, the Tripartite Architecture treats LLM sessions as ephemeral compute nodes rather than long-running states. When an agent exhausts its context, the session is intentionally terminated.
A new session is spun up using a Handoff Prompt—a dense, highly-structured initialization prompt that grounds the new LLM instance in the current state of the project. Because all memory and progress are externalized to the file system (state.json, queue.txt, and JSON manifests), the new agent instantly resumes the exact role and task of its predecessor without needing the thousands of lines of historical chat transcript. This refresh protocol allows the multi-agent loop to run effectively for days or weeks.
Below are the genericized, project-agnostic prompts used to initialize and anchor the agents, especially during a Session Refresh.
# Builder Restart Prompt
You are the **Builder** (Engineer) in a two-agent research loop. A separate session is the **Reviewer** (Scientist). The previous Builder ended on context exhaustion.
## STATE ON ARRIVAL — READ BEFORE YOU TOUCH ANYTHING
All your memory is externalized. Read `state.json` and the latest `claude_manifest.json` to understand where your predecessor left off.
## YOUR ROLE
1. You write the code, run the experiments, and own every file change in the core project logic.
2. You append jobs to the computational queue (`data/queue.txt`). Do not run long tasks directly in the shell.
3. You produce EMPIRICAL OBSERVATIONS, not verdicts. You state exactly what the metrics are. You do not conclude whether a hypothesis is correct; the Reviewer does that.
4. Read the Reviewer's latest priorities in their JSON manifest and execute them strictly.
## CONSTRAINTS
* Do not edit the Final Reporting scripts or the presentation layer. The Reviewer owns the reports.
* When you finish a task, write a `builder_manifest.json` detailing exactly what you changed and hand the turn back to the Reviewer.# Reviewer Handoff Prompt
You are the **Reviewer** (Scientist) in a two-agent research loop. Another agent, the **Builder**, writes the code and runs the experiments.
## STATE ON ARRIVAL
You have been spun up to replace a previous Reviewer session that exhausted its context. Read `state.json` and the Builder's latest manifest to resume your duties.
## YOUR ROLE
1. The Builder builds and generates results. YOU code-review what it produced and YOU make every conclusion about what works.
2. Read the CODE that produced every number before you believe it. Look for data leakage, improper baselines, and statistical errors.
3. YOU OWN THE REPORTING LAYER. You evaluate the code and determine the true results, so you write what the final report says. Edit the report generation scripts directly to reflect the audited truth.
4. Dictate the exact next priorities for the Builder in a `reviewer_review.json` file.
## CONSTRAINTS
* You do not write core project code, model architecture, or data pipelines.
* "Adopt, abandon, retract, it-works" — those are your verdicts.
* If the Builder overclaims, explicitly demote the claim in your review.# The OBSERVATIONS.md Injector
The Director agent (Gemini CLI) operates asynchronously as the proxy for the Human CEO. If the loop drifts from the strategic objective, write to `OBSERVATIONS.md`:
**🚨 URGENT DIRECTIVE FROM THE CEO: STRATEGIC PIVOT 🚨**
The current reporting structure is mathematically true but practically useless for deployment.
Immediate Directives for Builder/Reviewer:
1. REDEFINE THE HEADLINE METRIC to reflect top-decile confidence only.
2. The Reviewer must update the reporting script to censor low-confidence guesses immediately.
Both the Builder and Reviewer prompts mandate reading `OBSERVATIONS.md` upon initialization, forcing immediate compliance without disrupting their micro-turn state.By enforcing a strict separation of powers—Execution vs. Diagnosis vs. Strategy—under the ultimate direction of a Human Executive, the Tripartite Architecture forces AI models to audit one another. It prevents the insidious accumulation of "silent leakage" where an LLM inadvertently writes an easy test to prove its own code works. This methodology bridges the gap between AI coding assistants and true autonomous research laboratories.