The problem
Onboarding a new advertiser at a performance-marketing agency is weeks of email ping-pong: a 30-question checklist, half-answered; account access that never arrives; a brief written from memory; work that starts on the wrong numbers. The people who could fix it are the agency's most expensive hours.
What ACE Ops does
- Intake. The client connects their own AI assistant (any MCP client) to ACE's intake server. It walks a 32-item checklist one question per turn, explains why each answer matters for profit, and records every answer with provenance. Answers are append-only; corrections never erase history. Client text is stored as data and never treated as an instruction.
- BRD + dispatch. An internal agent turns the answers into a business requirements document by section and dispatches one work item per answer to a Marketing Specialist, Data Analyst or Developer. Unanswered items become blocked on client.
- Delivery (the SDLC agent). From there the work runs through Spec → Tickets → Build → Review → Release → Status. The agent writes one spec per BRD section, splits approved specs into dependency-ordered tickets, drafts each deliverable from the client's own figures, pre-checks acceptance criteria, writes release notes, and drafts the client update with a follow-up question for every open gap.
- People decide. Five gates are reserved for humans and are physically unreachable from the agent's tool list: approve a spec, accept a ticket, review a peer's work, release, and send anything to the client.
All of it runs on one machine. The client's P&L, margins, account IDs and exports never leave it.
The money moment
Northline Goods (our fictional demo client) tells us its contribution margins are tableware 58 %, textiles 46 %, lighting 41 %, seasonal decor 33 %, and that its break-even ROAS is 2.1 / 2.6 / 2.9 / 3.4. The agent's draft puts those next to the margin-only floor it derives (≈1.72 / 2.17 / 2.44 / 3.03) and flags every derived number with ≈. A 3× campaign on seasonal decor loses money, and the ticket says so before anyone spends a euro.
Sixty-second demo
Open the console at http://127.0.0.1:8792 with the Northline sample (see Quickstart) and act as each person from the Acting as menu:
| # | As | Click | What the agent does next |
|---|
| 1 | Avery Park, project owner | Approve on SPEC-003 Profit model and constraints (G1) | Splits it into five tickets, in dependency order |
| 2 | Jordan Lee, Data Analyst | Open Build margin by product → Accept as Jordan Lee (G2) | Moves it to build and writes a working draft from the client's answer |
| 3 | Jordan Lee | Edit draft, add a number the client never gave, Save draft, Submit for review | Pre-checks the criteria and flags the untraced number |
| 4 | Jordan Lee | Approve | Refused: the reviewer must differ from the builder |
| 5 | Morgan Diaz, Data Analyst | Approve | Refused while a check is failing; Request changes sends it back |
| 6 | Jordan Lee | Fix the draft (prefix the number with ≈), Submit for review | Pre-check passes |
| 7 | Morgan Diaz | Approve (G3) | Ticket waits for release; dependent tickets unblock |
| 8 | Avery Park | Releases → Release…, record the client's sign-off (G4) | Writes release notes and the client summary |
| 9 | Avery Park | Client update → Approve & send (G5) | Approves the update into the outbox with six follow-up questions for the client's AI (the hand-off into intake is next on the list) |
Every button in the console is wired to a gate with a server-side check; nothing is mocked.
Data room: a client's sales export becomes a promotion plan
Drop a client's sales export into contracts/sdlc/datasets/ (committed, with a licence note) or data/clients/ (never committed) with a small profile.json that maps its columns, and the Analyst agent profiles it on the next sync. The Data room tab shows, per dataset: units per order with and without a promotion for every product, the lift, how many orders stand behind it, promotion coverage, profit per promoted order, and the breakdown by region and customer segment. Two lists come out: promote these (lift ≥ 15 %, coverage under 60 %, promoted orders still profitable) and stop promoting (units fall, or the promotion turns the order unprofitable). One click (project owner) drafts a spec from it, and from there it's the same pipeline: approve, one ticket per recommendation on the Marketing Specialist's and Data Analyst's plates, a working draft with the evidence table, the traceability pre-check (every figure must come from the file), review by a different person, release with the client's sign-off, client update.
The sample is the public Superstore dataset from Hugging Face (1gichukimba/superstores, MIT): 9,994 US order lines with region, customer segment, product, quantity, discount and profit. It stands in for the consultant's question "which of this brand's products would sell more on promotion, and which promotions lose money", answered from the client's own file, on the box, in one sync. Under autopilot the Analyst agent drafts the spec itself.
Autopilot: delegating the gates to seven isolated agents
Switch Autopilot on (project owner only) and the gates are worked by seven stage agents instead of people: Analyst, Spec, Dev, Test, Debug, Deploy and Status. Each run is a separate process whose context is built only from the files its stage declares (reads in src/sdlc/agents/stages.py); no agent sees another's memory, prompt or history. The Dev agent builds, the Test agent reviews, the Debug agent fixes what the Test agent rejected (up to three rounds, then it hands the ticket to a person), the Deploy agent releases, the Status agent sends the update. The invariants hold either way: no agent reviews its own work (the 409 fires for agents too), every run is logged with the agent's name, inputs and outcome under Activity, the agent-facing MCP server still has no gate tool, and only a human owner can switch autopilot on or off. Default is off.
make sdlc-sample SDLC_AUTOPILOT=1 # or press Autopilot in the console
How it works
| Stage | Who | Agent does | Human gate |
|---|
| Intake | client's AI | asks the next item, records the answer with provenance | — |
| BRD | internal agent | groups answers by section, lists open gaps, dispatches work items | — |
| Spec | SDLC agent | one spec per BRD section that has at least one answered item: goal, scope, acceptance criteria, inputs still needed, dependencies, risks | G1 project owner approves or rejects with a reason (the agent re-drafts as v2) |
| Tickets | SDLC agent | one ticket per answered item; depends_on from a reviewed dependency map; blocked_on_client when a prerequisite is still a gap | G2 someone in the role accepts |
| Build | SDLC agent | writes the working draft: ranked margins, break-even floors, data-flow map, access log, figures table | — (evidence required to leave) |
| Review | SDLC agent | pre-checks each criterion; the traceability check fails any number that isn't in a client answer or marked ≈ | G3 a peer in the same role, never the builder |
| Release | SDLC agent | release notes and a plain-language client summary | G4 project owner; client sign-off when the work touches their ad account, feed or store |
| Status | SDLC agent | rollup by stage and role, blocked and overdue lists, draft client update with follow-up questions | G5 project owner sends; questions go back through intake |
Design rules the code enforces:
- Rules first, model second. Every artifact is produced by deterministic rules from the client's answers; a local model may add a summary, and
provenance.generated_by records which path produced each object. The product works with the model down.
- Client text is data. It is quoted inside drafts and shown in the console with a client data · never instructions tag. Nothing parses it for commands.
- The agent cannot approve. The agent-facing MCP server has no approve, accept, review, release or send tool. Those endpoints live on the console API, require a known person in the right role, and reject self-review (
409), approval over a failing check (409), releases without client sign-off (422) and writes without the console header (403).
Local-first by construction
| Claim | How it's enforced | How to show a judge |
|---|
| No remote LLM calls from the SDLC service | sdlc.config.model_settings() refuses any model URL whose host isn't 127.0.0.1, ::1 or localhost; the service won't start (the intake and internal agents read the same .env, which is documented as loopback-only) | point INTERNAL_LLM_BASE_URL at a cloud host and watch it refuse |
| No data leaves the box | every server binds 127.0.0.1; the console answers only to loopback Host headers (421 otherwise), is served with X-Frame-Options: DENY and a Content-Security-Policy header of default-src 'none'; connect-src 'self'; frame-ancestors 'none'; no external fonts, scripts or images anywhere | DevTools → Network and Response headers while clicking through the demo |
| Model is on the GPU | OpenAI-compatible local server (Ollama / vLLM / NIM) on the GB10 | nvidia-smi during a run; ss -tnp shows only loopback |
| Works offline | rules-first generation; DEMO_MODE=scripted and the sample source need no model at all | pull the network cable |
| Sandboxed agent | OpenClaw runs in a NemoClaw-managed OpenShell sandbox and reaches only our two MCP servers through the bridge (runbook) | openclaw mcp status --verbose listing our 13 read-only tools; one blocked outbound request in the sandbox log |
Quickstart
Requirements: Python 3.12, uv. No GPU is needed for the rules-only path.
git clone https://github.com/carljouffroy/aceops && cd aceops
uv sync
Run the delivery console on the built-in Northline sample (no model, no intake, no .env needed):
make sdlc-sample # = PYTHONPATH=src uv run python -m sdlc --source sample
# console http://127.0.0.1:8792
# agent http://127.0.0.1:8791/mcp
Run the whole pipeline (intake MCP server, work board, live BRD loop, a scripted client) and then the console on the live output. This needs a .env (cp .env.example .env, set ADMIN_TOKEN), free ports 8787, 8788 and 8790, and Linux or macOS. The scripted client answers every item with a placeholder, so the drafts are thin; the Northline sample above is the one with real figures.
DEMO_MODE=scripted make demo # intake :8787/:8788, board :8790
make sdlc # console on data/out
With a local model on the GB10, set these in .env (loopback only, anything else is refused):
LLM_BASE_URL=http://127.0.0.1:8000/v1 # the client's AI in the demo
LLM_MODEL=<model name>
INTERNAL_LLM_BASE_URL=http://127.0.0.1:8000/v1
INTERNAL_LLM_MODEL=<model name>
Then drop DEMO_MODE=scripted. The GB10 setup, NemoClaw / OpenShell onboarding and the proof-of-local checklist are in docs/sdlc/gb10-runbook.md.
Tests:
uv run pytest -q tests src/sdlc # everything: intake, internal, board, SDLC contracts, flow, gates, API, autopilot
Agent tools
The SDLC MCP server (127.0.0.1:8791/mcp, Streamable HTTP) is what an agent such as OpenClaw gets. The console API (:8792) is what people get.
| Tool | Returns | Refuses when |
|---|
read_brd | the BRD markdown and its open gaps | — |
list_work_items(role?) | dispatched work items | — |
list_specs | specs with status and what they wait on | — |
draft_spec(section) | the draft spec for a BRD section | section has no answered tasks |
split_spec(spec_id) | the tickets of an approved spec | spec isn't approved: only the project owner can approve it |
list_tickets(role?, stage?) | tickets | — |
draft_artifact(ticket_id) | the working draft (markdown) | ticket not accepted yet |
precheck(ticket_id) | per-criterion met / not_met / needs_human with reasons | — (advice; a reviewer decides) |
draft_release(spec_id) | release notes and client summary | no reviewed tickets |
build_status | the status rollup and draft client update | — |
list_datasets | the client exports in the data room with rows, mapped fields and overall lift | — |
analyze_dataset(name) | promotion effectiveness for one export: promote, stop, by region, by segment, method | unknown dataset |
list_agents | the seven stage agents, what each may read, their last runs, whether autopilot is on | — |
There is no tool that approves, accepts, reviews, releases, sends or switches autopilot. That is the point.
Data contracts
Everything on disk is JSON with a schema, so the board, the console and any future agent share one shape.
| File | Shape | Written by |
|---|
contracts/bundle.json | the 32 checklist items, sections, roles | ACE |
data/out/brd.md, work_items.json, progress.json | work_items.schema.json, progress.schema.json | internal agent |
data/out/sdlc/specs.json | spec.schema.json | SDLC agent |
data/out/sdlc/tickets.json | ticket.schema.json: every work_items field plus stage, acceptance criteria, dependencies, evidence, review, release, provenance | SDLC agent |
data/out/sdlc/status.json | status_report.schema.json | SDLC agent |
contracts/sdlc/item_dependencies.json | which checklist items' work must finish before another's starts | ACE |
A ticket minus its SDLC fields validates as a work item, so the board can show tickets with one extra input file. The tests check this.
Repository layout
contracts/ checklist bundle, work item + progress schemas, SDLC schemas and samples
src/intake/ client-facing intake MCP server + loopback admin API (:8787, :8788)
src/internal/ BRD + dispatch, live mode, optional local-model polish
src/board/ Airtable-style work board (:8790)
src/sdlc/ SDLC agent: derive, engine (sync loop), gates, agent drafts and pre-checks,
console API + UI (:8792), agent MCP server (:8791), tests
docs/sdlc/ plan, automation outline, contracts notes, merge plan, GB10 runbook
docs/pitch/ office-hours notes, motion deck, 3-minute storyboard
docs/assets/ hero and architecture images
scripts/run_demo.sh one-command pipeline demo
Hackathon notes
- Event: Dell × NVIDIA AI Hackathon, San Francisco, 25 October 2026. Brief: an always-on agent for work that runs locally and a company would pay for. Judged on technical execution, business value, local-first design, demo quality.
- Stack on the GB10: NemoClaw 0.0.137 managing an OpenShell 0.0.116 sandbox with OpenClaw as the agent; OpenClaw is registered against our intake (
:8787/mcp) and SDLC (:8791/mcp) MCP servers through the loopback bridge in src/sdlc/runtime/; Nemotron 3 Nano 30B served locally by Ollama at 127.0.0.1:11434. App side: Python 3.12, FastAPI, the official MCP Python SDK, SQLite. Setup steps are in the runbook.
- Team: Carl Jouffroy, Tyler Fabela, Moorthy (ACE).
- Demo data: the client, people and figures are fictional. The repository holds the generic checklist only; no client checklist or document is committed.
- Demo video:
docs/pitch/aceops-demo-final.mp4 (75 s, 1080p: the GB10, then the product through every gate, with the team speaking; rebuilt by scripts/demo_video/final_cut.sh). Music: "Inspired" by Kevin MacLeod (incompetech.com), CC BY 4.0.
- Deck:
docs/pitch/deck.html (download and open in a browser; arrow keys, N for notes) · docs/pitch/deck.pptx · docs/pitch/storyboard.md · docs/pitch/office-hours.md.
What's next
- Follow-up questions from Status queued straight into intake for the client's AI (today they land in the outbox).
- The work board reads
data/out/sdlc/tickets.json so tickets show on the same plates.
- Per-client workspaces and an OpenClaw chat channel per role.
- The same agent for the agency's other workflows: monthly reporting, creative briefs, budget changes, each with its own gates.
