A self-hosted sales department for one B2B company: twelve agents across Signals, Research, Outbound, Proposals, Renewals and RevOps, a Knowledge Layer they read but cannot rewrite, a VP of Sales agent that runs six stages every morning, and a control plane with every agent and permission in view.
What you build
| Part | What it is | What it does |
|---|---|---|
| Eyes | A Next.js control plane, dark, dense, ledger-style numbers | Dashboard, Agent Explorer, Activity Log, Permissions, plus one page per revenue function, the pipeline, a calendar and the Sales-OS files. Four KPI cards per page, each with a plain-language subtitle. |
| Brain | Claude Code, then an LLM through OpenRouter or Ollama | Claude builds it. The runtime model writes briefs, sequence lines, proposal prose, reply labels and the morning brief; a fallback chain and validators reject any id or amount not in the data. |
| Memory | Postgres, about forty-five tables, money in cents | Versioned Knowledge Layer documents, accounts, signals, briefs, enrollments, messages, deals, proposals, subscriptions, approvals, permissions, agent runs, an append-only activity log. Seven guards. |
| The gate | A deterministic knowledge gate over every generated sentence | A price not in the pricing document, a claim not on the approved list, a competitor statement not in the competitors file and every banned phrase are held. The UI shows the sentence and the rule. |
| Nervous system | One event bus, one permissions check, one socket pattern for the outside world | Every agent calls may(agent, action) first: auto, ask or never. CRM, mailbox, calendar, e-signature and billing are sockets: CSV in, signed webhook out, done only when the outside confirms back. |
| The human boundary | Hold / Approve on the five decisions that matter | High-value deals, prices and discounts, contract exceptions, strategy changes and escalations wait for a click; Postgres refuses to set them to auto. Only approved steps and meeting replies go out. |
Where this comes from
Structure Webworks published "How Agentic AI Is Shaping the Future of Sales": a B2B sales department where a VP of Sales agent sits over six revenue functions — Signals, Research, Outbound, Proposals, Renewals, RevOps — reads from a shared "Sales-OS file system", and stops for a human on high-value deals, pricing and discounts, contract exceptions, strategy changes and escalations. The control plane is five pages: Dashboard, Agent Explorer, Activity Log, Permissions, Settings. The link is in the files box. It is a good map. The part worth copying exactly is the approval list and the idea that agents read a folder of documents before they act.
Their article describes sixty-plus tools and twenty-eight live connections. Nobody here has wired one, so this pack connects to nothing by default: every vendor is a socket, and the only "connections" number the app shows is the count of outbound messages the outside world actually confirmed. What it builds instead is the honest version of the same shape: deterministic code does the gathering, one LLM call writes the sentences, a validator throws out any line that cites a deal, an account or an amount that is not in the data, and the Knowledge Layer is a set of versioned documents in Postgres with a gate in front of it — not a paragraph in a prompt.
What you build
When it runs, it feels like a sales manager who read every signal, every reply and every deal before you got in. A buying signal lands through a socket at 3 a.m.; the Account Scorer turns it into a fit score whose formula is printed on the page. The Account Researcher writes a one-page brief where every fact carries a chip you click to see the row it came from, and the made-up citation gets dropped by code. The Sequence Writer proposes an enrollment with every step rendered word for word; you approve it once and the steps go out on schedule through the email socket. A reply that says "can we talk Tuesday" books a meeting from a template you approved into a slot you opened. A reply that asks "what would this cost" stops the machine and waits for you. An unsubscribe stops it faster, with no click at all.
The Proposal Drafter does arithmetic over the pricing document; any discount, any non-standard term and any deal above your threshold is held, and Postgres refuses the shortcut even if the UI forgets. Renewals watches usage with a formula you can add up by hand and proposes the upsell; it is not allowed to send it. RevOps cleans the CRM by proposals you approve and computes pipeline, win rate, CAC, LTV and forecast accuracy from recorded rows, saying "not enough data yet" instead of guessing. Then the VP of Sales runs six stages every morning — route, prioritize, assign, monitor, forecast, escalate — and leaves a "Waiting on you" list with Hold and Approve on each line. When a deal closes, the loop proposes edits to the playbook. Proposes. You approve the edit.
Do you need this? Be honest first
If you sell to five accounts a year and know every buyer by first name, you do not need twelve agents; you need a spreadsheet and a calendar. This is for the B2B company with a real sales cycle — software, services, equipment, anything with a proposal and a contract — where signals go unnoticed because nobody is watching at night, where sequences go out with words nobody approved, where a discount gets promised on a call before anyone checked the pricing document, and where the forecast is a feeling. It is also for the builder who wants to sell that company a system it owns instead of a seat on somebody's platform.
You are building software that drafts outreach and proposals, not a licence to email anyone. The app has no mail sender in it. The email socket is where a real one goes later, and the company that wires one owns consent, unsubscribe handling and the rules that apply where it sells. If you are not comfortable saying that to a client, close the tab.
What you need
Pick the machine first:
| Option | Good for | Runtime model |
|---|---|---|
| Any laptop — Windows with WSL, Mac, or Linux with Omarchy | Learning and building | OpenRouter free models |
| A Mac mini with 64 GB or more | Running it in the office with local AI; prospect and deal data never leaves | Ollama with qwen3:32b or llama3.3:70b |
| A small VPS | Reachable from anywhere, awake when the signal lands at 3 a.m. | OpenRouter |
Every option needs Claude Code logged in (Pro, Max or Team), Docker, Node and git. The
pack assumes none of them are installed: the setup guide starts at "open a terminal"
(or install one — Windows Terminal, Tabby, PuTTY, Terminal.app, or Super + Return on
Omarchy) and ends when claude, docker and node all answer. It covers the
OpenRouter account (free models first, $10 of credit when the brief goes to a real
sales lead), Ollama on a 64 GB Mac, and a VPS if you go that way. No CRM keys, no
enrichment tokens, no mailbox access, no e-signature account: every outside platform is
a socket in this lesson, and demo mode ships a fake one that confirms by itself. Nothing
of the author's is in it; every credential is yours.
The setup guide is one HTML file you open in a browser. Every command has a copy button, every step has a checkbox, and a progress bar at the top shows how far along you are. Your progress is saved in that browser.
What is in the zip
agentic-sales-os/
README.md the document: what, why, hosting, the accounts, the folder map
index.html the clickable setup guide with all fourteen prompts (same as the browser link above)
COSTS.md every cost, with the date it was read
CREDITS.md where the idea comes from, the as-is notice, what was verified, terms
paths/ one README per platform: Windows WSL2, Mac Apple Silicon, Linux Omarchy
prompts/ 00-project-brief ... 13-tests-and-smoke
assets/ the cover art
What was verified and what was not
This pack is distributed as is, as a proof of concept. The setup guide was opened in a real browser and driven by a script on 2026-08-30: the three platform tabs, the progress bar, the checkboxes, the saved progress, and the copy buttons all work — including from a downloaded file, where the modern clipboard API silently fails and the guide falls back to the older method. The install commands are the current official ones for WSL, Homebrew, Docker, nvm, pacman and Claude Code as of that date; they were not executed end to end on three fresh machines for this release.
The fourteen prompts were written against a reviewed design, read twice by a separate model (Codex) for contradictions and missing steps, and have not been run as a sequence. Every prompt ends with a "how you know it worked" check that you can see without reading code — Postgres refusing a discount without its approval, the dispatcher sitting still on a paused enrollment, the validator throwing out a deal code that does not exist. Prompt 13 makes Claude break the code on purpose to prove the tests can fail. If a prompt breaks on your machine, paste the full error into Claude Code and ask it to fix it, then post what broke and the platform in the community.
Read the prompt before you run it
Hand each prompt to Claude first and ask what it plans to build. Compare that to what the prompt says. A prompt costs a minute to fix. A wrong build costs an afternoon.
