Plain-English summary: Do not ask one AI agent to build work and then grade its own work. Give one agent the implementation, give a second agent the acceptance criteria and evidence to audit, and keep humans responsible for product truth, legal judgment, money, brand claims, and production release.
Updated August 10, 2026 with a build-in-public field note from The Athlete Spotlight.
When several AI systems are helping with website builds, dashboards, reports, content, and client operations, the goal is not to make every agent do everything. The goal is to give each outcome a clear owner, create an independent review step, and leave a decision trail the whole team can follow.
This is the operating model we use for personal brand websites, local service business marketing, and the software that supports those services. It lets agents move quickly without quietly turning customers into production testers.
Why Should the Builder and Auditor Be Separate?
The agent that made a change already has a theory of why that change is correct. Asking it to approve its own work makes it more likely to repeat the same assumptions, miss the same edge cases, or treat its implementation notes as proof that the customer experience works.
Independent review is not just our preference. The NIST AI Risk Management Framework recommends involving internal experts who were not the front-line developers and/or independent assessors in regular assessments. The OWASP AI Agent Security Cheat Sheet recommends explicit approval and independent validation for high-impact actions.
Our practical rule is simple: the builder produces the change; the auditor produces the verdict; a human accepts the risk and authorizes consequential release decisions.
What Did a 24-Item Website Audit Teach Us?
On August 10, 2026, we audited The Athlete Spotlight, a program designed to help young athletes build a credible public presence, clarify their goals, attract opportunities, and learn how to market themselves responsibly.
The public context for that work includes Cam Hazzard’s personal brand playbook and our field note on Dylan Haugen and Jack Wendt’s authority work. The operating workflow below is the control layer behind projects like these.
The audit became a 24-item acceptance-test backlog covering the complete customer journey: site performance, mobile experience, proof and authority, scoring, signup, analytics, search visibility, privacy, claims, partnerships, and release controls.
Claude estimated that it could execute roughly 18 of the 24 items agentically. That was a dated implementation estimate, not a promise that 75% of every project can be automated. The more useful lesson was what remained: the final six involved business, legal, brand, or product judgment that software should not quietly make.
The queue is still being implemented, so this is a working protocol rather than a results case study. Attempted tasks, completed tasks, QA-passing tasks, released tasks, and measurable business outcomes are five different numbers.
| Good work for an implementation agent | Work that needs a human owner |
|---|---|
| Improve caching, image delivery, layout stability, accessibility, and mobile behavior | Define exactly what the offer includes and what it does not include |
| Implement approved signup, payment, analytics, and lead-routing requirements | Approve pricing, affiliate economics, attribution rules, and material partner terms |
| Add tests, staging evidence, event tracking, metadata, and production smoke checks | Approve athlete claims, testimonials, scoring philosophy, and missing-data rules |
| Draft pages and configurations from an approved source of truth | Review youth privacy, guardian consent, refunds, messaging consent, and legal language |
| Document known limitations and a rollback path | Decide whether the remaining risk is acceptable and authorize release |
The number of agentic items will change with the codebase, access, staging environment, and clarity of the acceptance criteria. The boundary should not change: an agent can implement an approved decision, but it should not invent the decision and then cite its own implementation as approval.
The same boundary applies to scoring. An agent can code, calculate, display, and test a score after people define the inputs, weights, missing-data rules, and meaning. A score produced by software is not automatically objective.
Who Owns What in the Builder–Auditor Model?
| Role | Responsibility and boundary |
|---|---|
| Human product owner | Owns: priority, scope, economics, accepted risk, and final go-live authority. Does not self-approve: technical evidence that has not been independently tested. |
| Implementation agent | Owns: code, configuration, tests, staging, deployment package, and rollback readiness. Does not self-approve: its own release. |
| Independent audit agent | Owns: acceptance criteria, strategy and UX review, evidence checks, regression testing, and the release verdict. Does not self-approve: code or configuration it authored for the same outcome. |
| Brand or subject-matter owner | Owns: name, image, voice, testimonial, performance claim, and customer experience. Does not self-approve: claims about the subject without the subject’s approval. |
| Operations owner | Owns: assignments, dates, access, decisions, meeting notes, and proof of completion. Does not self-approve: closing work with missing evidence. |
| Qualified counsel | Owns: privacy, minors and guardians, terms, refunds, consent, and affiliate language. Does not self-approve: unreviewed drafts represented as final policy. |
Claude and Codex are the current builder and auditor in this case, but the model names are interchangeable. If Codex builds a future change, Claude or another qualified reviewer should audit it. Separation of duties matters more than loyalty to a vendor.
Why Do We Keep One Task for One Outcome?
A common failure mode is creating separate build, fix, QA, and deployment tasks for the same customer outcome. The implementation gets marked complete while the QA task remains open somewhere else, and the dashboard reports progress that the customer cannot experience.
We keep the implementation, audit findings, fixes, deployment evidence, and production smoke test in the same canonical task. A new task is warranted only when the audit reveals a genuinely separate risk or outcome.
That gives the team one place to answer four questions:
- What customer outcome did we promise?
- What changed?
- What evidence proves it works?
- Who accepted the remaining risk?
What Is the Nine-Step Workflow?
- Prioritize: The product owner chooses the existing task and names the intended outcome.
- Define: The auditor writes or reviews measurable acceptance criteria. Humans approve material product, claim, privacy, and economic decisions.
- Implement: The builder works in source-controlled staging, not directly in production.
- Hand off: The builder posts a READY FOR QA package with the preview, version, test results, evidence, limitations, customer or data impact, and rollback instructions.
- Audit: The independent reviewer tests the experience and posts PASS, PASS WITH FOLLOW-UP, or FAIL with evidence.
- Fix: Failures return to the builder inside the same task. The task stays open.
- Authorize: After staging passes, the human product owner approves production release.
- Verify production: The builder deploys and the auditor runs the production smoke test.
- Close: Operations closes the task only after the production result and evidence are recorded.
This is a smaller, operational version of our broader practice of turning recurring decisions into documents and agent instructions so the knowledge outlives any one conversation.
Where Do Basecamp and GitLab Fit?
Business decisions should not live only in chats or meeting recordings. For this project, Basecamp holds the customer outcome, owner, due date, approvals, QA evidence, and decision history. Any decision made on Zoom is summarized there with an owner and deadline.
GitLab holds the code, branch, diff, tests, review, release version, and rollback path. One system tracks why the work matters and whether it is accepted; the other tracks exactly what changed.
That distinction matters. A green code pipeline does not prove the signup journey makes sense to a parent. A Basecamp comment saying “looks good” does not prove the deployed code matches the approved version. The two records must point to each other.
What Evidence Must the Builder Hand Off?
This is the copy-ready handoff template we use:
READY FOR QA
Staging or preview URL:
Commit, build, or version:
Scope completed:
Acceptance criteria and results:
Mobile and desktop evidence:
Known limitations:
Customer or data impact:
Rollback instructions:The auditor responds in the same task:
QA VERDICT: PASS / PASS WITH FOLLOW-UP / FAIL
Acceptance criteria checked:
Evidence:
Mobile and desktop result:
Security and privacy result:
Analytics result:
Regressions:
Required fixes:
Production smoke-test status:A screenshot can support a result, but it is not enough by itself. The reviewer should test the live behavior, read the system response where possible, and verify from the customer’s side of the experience.
What Do PASS, PASS WITH FOLLOW-UP, and FAIL Mean?
- PASS: The requested outcome and every blocking acceptance criterion work in the tested environment. The item is eligible for the next human-controlled release step.
- PASS WITH FOLLOW-UP: The requested outcome works and the remaining findings are genuinely non-blocking, assigned, and dated.
- FAIL: A blocking criterion is not proven, a regression exists, or the evidence is incomplete. The task returns to the builder and remains open.
Any unresolved issue involving security, privacy, payments, legal exposure, youth data, data integrity, or a materially false claim is a FAIL. The builder does not earn the right to say “done”; its evidence earns the right to be reviewed.
How Do We Scale Oversight Based on Risk?
- Green: copy, styling, documentation, tests, and low-risk configuration. The agent can prepare a preview for approval.
- Yellow: forms, dashboards, integrations, analytics events, report code, and ordinary product features. Require independent review and staging.
- Red: authentication, permissions, billing, pricing, migrations, deletion, production data, youth privacy, public claims, or ad spend. Require focused tests, explicit human approval, and a verified rollback path.
This is why a managed agent can have a long runway without receiving unlimited authority. Runtime and permission are different things.
What Does “Done” Mean?
A task is not done because code exists, an agent says it is done, or a page loads. For most website and dashboard work, completion includes:
- Every acceptance criterion passes
- The requested behavior works on desktop and mobile
- Accessibility and performance budgets are respected
- Forms, lead routing, SEO metadata, and analytics events are verified
- Required brand, subject, product, and legal approvals are recorded
- Screenshots and logs expose no credentials or personal information
- The independent review is resolved
- The release and rollback path are documented
- Production passes the final smoke test
The Client Tracker records who owns each account, while a scoped WordPress Application Password can give an authorized agent access to the specific site it maintains. Access is plumbing; it does not replace approval.
What Do We Publish When We Build in Public?
Building in public does not mean publishing every operational detail. It means sharing the reusable lesson while protecting the people and systems that made the lesson possible.
| Useful to publish | Keep private or abstract |
|---|---|
| Roles, workflow, acceptance criteria, and handoff templates | Credentials, access tokens, private project links, IDs, and personal contacts |
| Dated backlog counts and broad work categories | Unresolved contracts, private economics, and draft legal language |
| What an agent estimated it could do and what humans retained | Exploit details, production weaknesses, or instructions that increase security risk |
| Lessons, failure modes, and verified outcomes | Youth, guardian, applicant, customer, or employee personal data |
That is the line we used here. We are sharing the operating agreement and the 24-item/roughly-18-item lesson, but not the private project URLs, contacts, access details, contractual economics, or security specifics behind the audit.
The percentage of work an agent can attempt is not the percentage safe to release. Building in public means exposing the reasoning and reusable method, not exposing access, people, or vulnerabilities.
What Usually Goes Wrong With Multi-Agent Work?
- One agent builds and self-certifies. The same blind spot survives both steps.
- Two agents implement the same feature. The team gets competing branches and a merge problem instead of parallel progress.
- Implementation and QA live in separate tasks. One closes while the customer journey is still broken.
- A meeting becomes the source of truth. People remember different decisions and nobody owns the follow-up.
- “Agentic” is mistaken for “autonomous authority.” The agent quietly makes pricing, legal, brand, privacy, or release decisions.
- Evidence proves the build step, not the user experience. A successful deployment is reported as a successful product.
Frequently Asked Questions
Do the builder and auditor need to be different AI companies?
No. They need separate roles, context, and deliverables. Using different model families can reduce shared blind spots, but independence comes from the reviewer testing against acceptance criteria and evidence instead of inheriting the builder’s conclusion.
Does a second agent double the cost?
Usually not. The auditor does not need to rebuild the feature. It needs to inspect the changed surface, run the right tests, reproduce the customer journey, and report exceptions. Targeted review is usually cheaper than recovering from a bad production release.
What can an AI agent do without human approval?
Read-only analysis, drafts, tests, and reversible low-risk changes can often proceed within an approved scope. Financial, destructive, legal, privacy-sensitive, externally visible, or production actions need stronger controls and a named human authority.
Who decides whether a QA failure can be accepted?
The human product or release owner. The auditor’s job is to make the risk visible and evidence-based. A human may accept a risk, but the reason, scope, and follow-up should be written in the canonical task.
How do Basecamp and GitLab avoid becoming two competing sources of truth?
Give each system a different truth to own. Basecamp owns the business outcome, assignment, approval, and QA record. GitLab owns the code, version, tests, and release artifact. Cross-link them rather than copying their contents.
The Operating Principle
Use one primary builder, one independent reviewer, deterministic data, staged releases, and human control over money, claims, personal data, and production. Keep the outcome and decision trail in the project system and the implementation history in source control.
If you want to build this workflow yourself, start with our guide to setting up AI agents for your business. If you want help converting your projects into bounded agent work with an independent QA gate, talk with the Local Service Spotlight team.
Disclosure: This article was repurposed from a live internal operating protocol and redacted for public use. It excludes private project links, credentials, youth data, legal drafts, security findings, and commercial terms. AI assisted with drafting and review; Local Service Spotlight retains responsibility for the published claims.