The manifesto · Updated October 2026
HALO: Human Agentic Lifecycle Orchestration
How one person drives an AI system to do the work of a team, without letting anything run away from them.
By Bob Michaels · Austin, Texas
Whose court is the ball in?
I run many client projects at once. I can't hold them all in my head, and I shouldn't have to. HALO keeps track and shows me in seconds whether I'm holding anything up.
When work is stuck, HALO names who it's waiting on: me or the client. Before I report a block, I ask what I could hand over to move it. HALO reports where things stand while the work is happening, so work that reports nothing doesn't look like stuck work.
If I've handed the client everything and I'm waiting on them, that's a good day. If something sits undone on my side while I'm waiting on the client, that's the failure HALO exists to prevent. My goal is to be the party that never makes something late.
The point
I have a lot to juggle every single day: emails to answer, proposals to get out, research on clients, prospecting, meeting prep, decks, software to ship. The point of this methodology is simple: get more out of every minute I am in front of my computer. The AI is the engine underneath everything. I am the driver. Nothing here is exotic. It is a way of working.
I know how to build software and architect systems, and many people have that capability. What most people do not have is a disciplined way to point AI at their whole working life at once. That is what this describes: the philosophy, then the specific habits and patterns that amplify one person into something much larger.
The philosophy: orchestration, not autonomy
The industry keeps publishing stories about autonomous agents burning money writing code nobody asked for. HALO is the opposite bet. Nothing in my system runs autonomous except managed background agents on specific, bounded tasks that I review afterward. A human orchestrates everything.
The human in charge is the design. The person deciding what matters is the cost control, because spend follows judgment. It is the quality mechanism, because every deliverable passes a person before it ships. And it is the trust mechanism, because everything that happens has an author, a reason, and an audit trail.
The lifecycle is the variable
HALO did not stay a way to build software. The thing being orchestrated is a lifecycle: a body of work with stages, gates, and deliverables. Software delivery was the first one I ran this way and it is still the sharpest example, but the discipline is the constant and the lifecycle is the variable. The same method now runs my editorial production end to end: measure how the AI models describe a market, set the strategy, draft on verified sources, put the draft through an adversarial reviewer whose only job is to refute it, panel-test it blind across five models, take a final human edit, publish, then measure the result and fold what I learned back in. Email, proposals, research, decks, code, content: each is a lifecycle, and HALO runs them the same way, from the same knowledge base, through the same human-approved gates.
The operating cycle
Two disciplines run together. Structure says where context lives: what each folder means, what loads at each stage, one source of truth per fact. The cycle says what happens next: discuss the outcome, research when the work depends on external facts, pre-mortem when the consequence warrants it, plan, execute, verify against explicit acceptance criteria, fix by replanning when verification fails, summarize what happened, and pass a human gate before anything advances.
A stage is a bounded unit with one job, one contract, one output area, one evidence record, and one human gate. That shape is what lets the same method run software, research, editorial, and client work without the discipline degrading.
The architecture
A knowledge base of plain markdown files holds everything about the business: every engagement, decision, method, and person, current at all times. It lives in a private git repository, and that choice is load-bearing. Because the corpus is markdown, git gives it versioning, synchronization, access control, and an audit trail for free. Every change has an author and a history.
An orchestrator session works at the business level and knows the whole picture. Project sessions work downstream, each rooted in one repository. Managed sub-agents fan out underneath on bounded tasks. Everything reads the knowledge base and everything writes back to it. The model does none of the remembering; the knowledge base does none of the reasoning. The model is rented and swappable. The knowledge base is owned, and it is the asset that appreciates.
The cockpit
The interface that makes this workable is the cockpit: a single, centralized view over the entire operation. Instead of a scatter of repositories, editor windows, terminals, and browser tabs, one screen pulls every project's assets into one place, its state, its files, its live terminals, its deliverables. I bounce between projects and terminals from that one surface, dropping into whichever workstream needs me and back out without losing my place.
It is built to manage and to do, not only to display. From the cockpit I direct edits to documents, proposals, and live websites and watch them happen in the workspace, then approve. The dashboard shows what needs attention; the terminals are where I direct the work; the knowledge base underneath keeps every surface on the same current picture. One human, one interface, every workstream in reach.
The disciplines
These are the habits that make it work. None are optional. Each exists because its absence broke something.
- 01Write at the moment of decision. Every decision, status, and verified fact is written and pushed the instant it happens, by whichever session did the work. Session end is a sweep, not the first write.
- 02Read state, never re-derive it. A session starts from the index and the one relevant state file, not a cold scan of the whole corpus. Nobody pays the cold-start tax twice.
- 03Unknowns stay unknown. A fact that is not known is marked and flagged, never filled with a plausible guess. Half the value is what the system refuses to make up.
- 04Single source of truth. Every fact lives in exactly one place; everything else links to it. Copying is how a knowledge base rots.
- 05Record everything. Meetings, documents, and every channel feed the knowledge base. Feeding the system is not overhead, it is the methodology.
- 06Version work, lock the numbers. Client work iterates under explicit versions. Once a figure is set it is locked: a later instruction can change styling, never a number.
- 07Publish nothing unverified. Every claim traces to a source the reader can check. If it cannot survive the reader pasting it into an LLM and asking if it is fair, it does not ship.
- 08Nothing autonomous runs unmanaged. Sub-agents fan out on bounded tasks and report back for review. Managed, monitored, documented. Never free-running.
- 09Adversarial review, never self-confirmation. A reviewer is asked to find failures, not to confirm quality. What each pass disproves is the value.
- 10Promote learnings only on repetition. A pattern earns its way into shared methods, templates, or tools after evidence shows it repeats. One success is an anecdote.
How the system knows what to do
A new session starts by reading a short handbook, an index, and the state file for its project. Standing rules live in files every session loads.
Hooks run before an action and enforce rules that must never be broken, such as refusing to change another project’s repository or build anything without my yes. Rules that depend on memory can fail, so I enforce the important ones with code.
How it follows instructions
The system records my instruction word for word when I send it. Before work starts, a plan’s steps go onto a board. Each commit is stamped onto the steps it completes.
When a session stops, the next one sees anything addressed to it and every new lesson. I choose the maker and model for each kind of work in one dropdown, and the tools refuse any other choice.
How it checks its own work
A second engine tries to reproduce defects in a change instead of reading it. For each page, the system opens every link, compares every quotation and contact detail with the brief, and reports "could not verify" when it can’t verify something.
A check that reports zero must first catch a planted defect. I don’t trust a clean result until it passes that test. Work counts as done only after the independent check passes.
Who writes the words
After news that one vendor marks text its models write, I separated writing from thinking. A model run by independent hosts writes every published sentence. Reasoning models brief, judge, and report; they never write the copy.
Each writer gets my style rules before its first word. A writer that can’t receive them doesn’t run. A check lists any passage the writer didn’t produce.
Mistakes become lessons
Every mistake a project pays for is written down once as a lesson. There are more than one hundred lessons.
The next session in every other project gets each new lesson automatically, so a mistake is paid for once.
Problems we hit and fixed
Grading one page once took about two hours because every question started a fresh heavy model process. Reading in parallel and a lighter judge, set in one configuration line, fixed that. An unpriced model reported a cost of zero while billing for real, so I now treat a zero reading as a bug.
A control installed across every project at once stopped real work. Shared controls now go to one project first, fail open, and record; I measure before and after. A control that can’t be satisfied must not hide its own failure. Fixing a tool doesn’t fix its earlier output, so I list every figure from a broken method and recheck it.
Quality: adversarial by design
Work products get reviewed by a different model family than the one that made them. A proposal drafted with one model goes to another to be attacked: the math checked, the claims refuted, the fixes brought back. A reviewer told to confirm will confirm, so the value is in what each pass disproves, verified against the real source before anything is folded in. On top of that sits a human approval gate on everything outbound, a pass that strips the tells of AI-written prose, and the audit trail that makes every decision inspectable after the fact.
The economics
Two mechanisms keep this affordable. First, the human in the loop, so tokens go where judgment says they should. Second, model tiering: a frontier model handles orchestration while much cheaper models do the downstream and routine work, which saves money and keeps the main context clean. A client who is not building software never needs the expensive tiers at all.
The asset that appreciates is not the model. Models are rented and swappable. The knowledge base is owned, and it compounds: every session, every terminal, every person using the system writes back to it, so it knows more and works better the longer it runs and the more it is used.
Using HALO
For my own operation, this runs today with the cockpit as the interface. For a client, it deploys as a managed service: the same architecture on their infrastructure, their knowledge base in plain files they own, commercial APIs doing the reasoning under documented no-training and retention terms, every professional getting the same prioritize-triage-approve loop. The way of working is the credibility. The service is the business.
Want this working in your organization?