Dream Team Protocol
A four-voice reasoning method for hard decisions: B reframes and breaks false limits, C formalizes and quantifies, S attacks weak claims, X brings domain knowledge. The point is productive argument, not consensus theater.
Structured human–AI collaboration for long-horizon research, engineering, and judgment.
AIM³ is the operating system behind this portfolio: a practical framework for working with advanced AI systems through defined roles, persistent state, workflow rounds, trust rules, decision trails, and reusable skills. The original architecture and guiding concepts are Bojan Dobrečevič’s; LLMs act as collaborators, builders, critics, reviewers, and amplifiers inside the structure. External AI reviews and articles are patch material, not a replacement for human authorship.
Ordinary chat is good for short tasks. It breaks when the work becomes multi-step, novel, adversarial, and cumulative. Decisions get buried. Constraints drift. Different sessions contradict each other. One model gives one answer, another gives a different answer, and the reasoning that produced either answer is rarely preserved in a reusable way.
The AIM³ principles document frames the core problem directly: humans carry an internal loop of continuity and self-argument, while standard AI chat is reactive — prompt, response, gone. That makes long-horizon thinking brittle.
Long projects lose accepted facts, rejected paths, priorities, and the exact reason one option beat another. Without explicit state and records, every new session risks partial amnesia.
It replaces loose prompting with an operating model: give the work roles, give it memory, force explicit rounds on serious tasks, keep a trust contract to reduce vagueness and sycophancy, and leave behind trails that the next session can continue instead of re-guessing.
In the protocol, AIM³ means AI Management of Mind & Memory: infrastructure for AI teamwork, not just a bigger prompt. It combines role-based reasoning, persistent session state, workflow rounds for serious tasks, and a trust pact that sets the tone and rigor of the collaboration.
A four-voice reasoning method for hard decisions: B reframes and breaks false limits, C formalizes and quantifies, S attacks weak claims, X brings domain knowledge. The point is productive argument, not consensus theater.
One project state file tracks stable facts, session log, current next steps, and a restart prompt. That gives continuity across sessions and models without pretending memory will manage itself.
Serious work gets a structured pipeline. The protocol distinguishes simple, medium, large, and wide-funnel tasks, escalating from light verification to full rounds: spec, panel, verification, synthesis, audit, acceptance.
The pact defines how the collaboration should feel and how rigor should work: equal thinking partnership, honesty over agreeableness, blunt but non-demotivating tone, evidence tiers, and tests outranking opinions.
Non-trivial choices are not left as vibes. AIM³ records criteria, weights, scorecards, sensitivity, and the decision record itself. Session logs keep the timeline short, readable, and recoverable.
AIM³ should not force every visitor to learn the full stack before they can use it. RHPm — AIM³ Prompt Builder is the compact entry point: it takes a normal human prompt, clarifies intent, checks missing lenses, adds acceptance criteria, and outputs a copy-paste prompt for a fresh LLM session.
Python builders, HTML page upgrades, Word/document work, reviews, audits, research plans, and any task where a weak starting prompt would waste the next session.
RHPm adds the minimum useful AIM³ discipline: explicit role, goal, files/context, constraints, workflow, deliverables, validation, stop conditions, and optional skill extraction.
RHPm is the daily prompt forge. RHPr is the anti-lock retrieval protocol when the model is stuck in the wrong knowledge basin. RHP is the heavier multi-perspective scaffold for hard cross-domain synthesis. AIM³ is the operating system that remembers what happened and turns repeated work into skills.
AIM³ is not only a better prompting style. It is a way to turn difficult or repeated human–AI work into named, tested, reusable skills. A loop without skills re-derives the same context and repeats the same mistakes. A loop that calls sharp skills becomes cumulative intelligence.
If the team does something more than once, extract a skill. If the team solves something hard once, extract the skill before the difficulty is forgotten. Each skill should name when to use it, when not to use it, required inputs, outputs, validation, failure modes, and one small example.
A bad skill compounds mistakes. Agent 0 therefore protects the registry: no skill is promoted without a fitness function, a failure-mode note, and a cheap retest path. Skills can be ready, experimental, rejected, or retired.
Loop engineering says: stop manually prompting every step; build loops that prompt agents. AIM³ adds the compounding layer: loops should not call strangers. They should call named, tested skills, update state, and make the next loop cheaper.
The operational loop is simple enough to run daily and strong enough to support frontier work. A problem enters the system. Roles attack it from different angles. Higher-stakes tasks move through explicit rounds. The human lead decides what counts. The result gets written into state and logs so the next session starts from the actual frontier, not from scratch. When the work was hard or repeated, the loop also extracts a skill.
Every serious round ends with a verdict: what stays, what changes, what is rejected, and what must be tested next.
AIM³ stays compact by default. The protocol explicitly says to expand only when the added detail serves the task. That keeps the system usable in real work instead of turning it into bureaucracy.
When stacks, tools, or architectures are in dispute, AIM³ pushes the team toward criteria, weights, scoring, sensitivity, and a written record of why a choice was made.
The bundle includes a full Dream Team example from the audio roadmap. Five ideas were put through multi-voice argument. The important result is not just that ideas were discussed — it is that the dialogue changed the architecture in concrete ways.
“Save overhead bytes.” “Try two-pass.” “Maybe use math generators on residuals.” On their own, these are directions, not designs.
The example turns those directions into specific outcomes: FLAC-minimal as a zero-overhead candidate, informed candidate pruning in two-pass architecture, stronger periodic prediction, a practical 8za2flac path, and a physical audio model library.
The example explicitly states that the key breakthrough emerged through argument: a skeptical attack forced the expert voice to stop hand-waving and reach for concrete physics, which then became a formal architectural path. That is the point of AIM³. It uses structured conflict to convert vague possibility into testable design.
Long research programs need accepted facts, open questions, and rejected paths to survive across months. AIM³ gives that work a durable shape instead of relying on memory, chance, or a single model’s mood.
Engineering improves when disagreements are explicit, tests outrank opinions, and tradeoffs are written down. AIM³ turns that into routine practice rather than leaving it implicit.
The future of human–AI work is not a lone user chatting with a compliant assistant. It is humans directing structured teams of specialized systems with memory, adversarial pressure, and continuity over time.
AIM³ is not presented here as a hypothetical framework. It is the operating layer behind the documents, code, reviews, and cross-domain project work shown across the broader BD × AI Lab portfolio.
AIM³ is a practical answer to a real problem: how to keep advanced AI collaboration coherent when the work becomes serious. Not bigger prompts. Not vague “AI agents.” A working operating model for long-horizon human–AI collaboration.