I Architected My Agent With SCoI. Here Is the Layer-by-Layer Build.

A founder building an internal sales-ops agent for a mid-market B2B company told me that two weeks ago. The team had spent six weeks on a prompt-engineered chat surface that nobody used. They pulled up Supply Chain of Intelligence™ (SCoI), walked the layers, and rebuilt the architecture in a day. Seven weeks later they shipped a working agent that the sales org actually adopted.

This is the public write-up of how they did it, layer by layer, with permission. Names are abstracted. The structure is real, and it's a clean illustration of using the framework as an architecture tool instead of a scoring tool.

The definition that drives the whole thing is the same one the investor lens uses: intelligence is a supply chain. Value accrues at the bottlenecks. Build accordingly.

The brief

An agent for a 40-person sales team. Jobs: pre-meeting research, account summarization, post-call CRM hygiene, and (eventually) outbound sequence drafting. Buyer is the VP Sales. Budget is internal. The constraint that mattered most: the team has six engineers and ninety days.

Old plan: ChatGPT wrapper over Salesforce, prompt-engineered, voice in Slack. Pretty demo. Zero adoption after launch.

New plan: walk the ten layers, decide each one explicitly, ship the smallest stack that owns at least one vertex of the Defensible Triangle.

L-1 and L0: rent, with one decision

Resources and Infrastructure are not the build. Cloud is the team's existing AWS account. Models hosted on Bedrock for procurement reasons, not technical ones, the company already had the contract. The only L0 decision worth making was L0e edge versus pure cloud. They chose cloud for v1 because latency for an internal sales tool doesn't justify edge complexity. Revisit if voice-on-call ever becomes the surface.

Decision: rent everything. Two engineering days, mostly procurement.

L1 Data: the first real fork

This is where the build actually starts. The question the team asked themselves, prompted by the framework: what data does our agent have access to that a horizontal sales agent (Apollo, Clay, the inevitable Salesforce-native Einstein replacement) cannot get?

Three answers, in order of moat strength:

L1b Proprietary. Closed-won and closed-lost deal histories, with notes, going back four years. The CRM has it; the horizontal players don't. Build a clean ingest and a labeled training set. This is the company's only real moat at L1.

L1c Behavioral. Email open/reply patterns, call recordings (Gong), Slack threads where deals get discussed. Already collected, never used as a corpus. Build a pipeline to extract it into a queryable form.

L1d Outcome. What the agent suggested vs. what actually happened in the next two weeks. Don't build this in v1. Instrument it in v1 so v2 can build it. This is the single most common L1d mistake, teams skip instrumentation, then can't bootstrap outcome data when they need it.

Decision: build L1b ingest, L1c pipeline, L1d instrumentation. Two engineers, three weeks.

L2 Models: rent, route at runtime, fine-tune later

No fine-tunes in v1. Frontier model for reasoning steps, mid-tier for summarization, embeddings model for retrieval. The team avoided the L2d trap of building a “smart router” as a product, L2d is a sublayer, not a company. They wired routing into L6 instead (see below).

Decision earmarked for v2: fine-tune a small model on the closed-won/lost corpus once L1b is clean. That fine-tune is the kind of L2b move that compounds the L1b moat, models that other companies cannot reproduce because they don't have the data.

L3 Gatekeeping: under-architected nowhere

The team's instinct, like most teams', was to skip L3 in v1 and add it later. The framework caught it.

Sales agents touch revenue forecasts, customer commitments, and pipeline data that ends up in board decks. Law IV says: generation and verification must be separate. If the agent suggests an updated close date or a new opportunity amount, a human (or a second model with a different prompt) has to sign off before it writes to Salesforce.

Decision: build L3b Quality Gates as a separate verification step for every CRM write. Build L3c Provenance so every agent action has a trace. Skip L3a Compliance until the agent leaves the internal org. Two weeks of work that the team almost cut. They didn't, and that's the reason the sales VP approved the rollout.

L4 Access: rent the pipes, design the seams

Salesforce API, Gong API, Slack API, Outlook (or Gmail) API. All rented. The L4 decision that mattered: build a thin internal connector layer so the agent doesn't talk to vendor APIs directly. Two reasons, both framework-driven. First, L4 is the substrate that gets the most churn, vendors deprecate endpoints, change auth flows, raise prices. An internal abstraction makes those changes one-file fixes. Second, when MCP-style connectors mature, swapping the underlying transport is local, not architectural.

Decision: rent every vendor API, wrap them in a small in-house L4 facade. One week.

L5 Execution: the actual product

This is where the team's engineering hours mostly went, correctly. Three skills shipped in v1:

L5a Tool use, the agent calls the L4 facade to read CRM, read Gong transcripts, read inbox threads. No writes without an L3 gate.

L5b Reasoning scaffolds, structured prompts for each job (pre-meeting brief, post-call summary, CRM hygiene). The scaffolds are versioned and evaluated, not free-form prompts. Versioning the scaffolds is what made the eval loop possible, without it the team would have been tuning vibes.

L5d Operating playbook, a codified description of how this company runs sales, MEDDIC-flavored, specific stages, specific exit criteria. The playbook is the company's IP and the most defensible sublayer on the whole stack. It is also the layer a horizontal sales agent cannot replicate without buying the company.

Decision: invest disproportionately here. Four engineers, six weeks. Worth every hour.

L6 Orchestration: small, sharp, boring

Loop, role routing, context. The team picked an off-the-shelf agent framework, ripped out the parts they didn't need, and kept the loop tight. L6d Context Management is where they spent the most time, getting the model the right slice of the L1 corpus per step without exploding the context window. Retrieval at L2c, ranking at L6d, that seam is where most agent failures happen and where most teams under-invest.

Routing logic (which model for which step) sits here, not in a separate L2d service. Framework-consistent: L2d is the capability, L6 is the runtime that uses it.

L7 Surface: pick the buyer's existing habit

Slack and Outlook. Not a new app. Not a chat box on a dashboard nobody opens. The framework's read: surface should ride the user's existing attention, not compete for it. Sales reps live in Slack and email. The agent shows up there. L7a for conversational queries, L7e for async digests (morning pre-meeting briefs, end-of-day CRM hygiene nudges).

Decision: build inside two surfaces the team uses anyway, ship no new app.

L8 Memory: thin in v1, designed for v2

The single most important v1 decision: start L8, even if thin. Session memory and user profiles in v1 (L8a, L8b). Schema for institutional knowledge (L8d), what closed-won deals look like, what objection patterns repeat, what playbook variations work for which account type, designed in v1, populated continuously after launch.

L8c (aggregated network learning) and L8e (learned world models) are v3 problems. But the schema lives in the v1 database. Bolting memory on later is twice the work; framework warning applied verbatim.

What the build looked like at the end

Seven weeks, six engineers. Stack owned: L1b + L1c + L5a/b/d + L8a/b in v1, with L1d and L8d instrumented and waiting. That's two vertices of the Defensible Triangle in v1, with the third (L8d) on the runway. The horizontal sales agent that will inevitably arrive can replicate L5a and L7. It cannot replicate this company's L1b or this company's L5d.

Adoption after launch: 31 of 40 reps active in week three. The VP Sales is the internal sponsor for the v2 budget. The framework didn't write the code. It wrote the order in which the code got written, and that was the difference.

The transferable lesson, not the specifics

Most agent builds fail at the L7 → L5 → L1 inversion. Teams design the chat surface first, then bolt skills on, then realize they have no proprietary data and no memory. The framework forces the reverse order: L1 first (what do we know nobody else does), L5 second (what do we do with it that's hard), L8 third (how does this compound), L7 last (where does the user meet it).

That order is the architecture. The same ten layers an investor uses to verdict a company are the ten boxes a builder uses to design one. The definition that holds the whole thing together is the one that has not changed since day one: intelligence is a supply chain. Build at the bottlenecks. Rent the rest.

The full framework, ten layers, fifty sublayers, four laws, and the Agent Decoder, is free at supplychainofai.com. No signup, no paywall.

- Anand