Building a shared context layer for GTM

TL;DR

I built a shared, GTM context layer, after watching countless AI projects/tools die. It’s addressed in Slack by @Junto, has a visual graph composer as the backend, and is built on top of a set of events that the business is normalized into.

• The problem: Projects, whether they were Claude projects, dashboards, or purchased platforms, all eventually died. The result was that everyone had their own version of what worked, minimal visibility into what others were building, and no compounding knowledge.
• The argument: I believe that what all of the projects were missing were ‘relationships’. Relationships to the workday, to teammates, to the tool’s own failures, and to every other piece of GTM work.
• The fix: A shared, compounding knowledge layer. The aforementioned dead projects were places you had to go to, and they competed with your day for time. We built Junto as the layer for what any project could be built on, native to the one place that GTM was already in.
• The output: 2 surfaces, Slack as the front door, and a backend where plays are editable blocks on a canvas, built from 1,000+ triggers and integrations. Underneath, an open source engine, a constitution injected at exactly one seam, a deterministic linter that outranks the model, and a set of rules living below the model that must always hold. Every answer comes back with a diagram drawn from the run’s own trace, and every play carries who built it. Data arrives through one validated funnel and waits for human sign-off before it’s real, and outbound never sends: it drafts.
• The results: I pressure-tested it with a simulated 120-person GTM team. 0 permission leaks across 432 requests, the 6 accounts planted to bait a cross-channel read refused 6 of 6 times, lookups at 13 milliseconds at the 95th percentile, and 100% of cited facts verified word for word against the data.

Five examples of prompts that could only be answered from a system like Junto:

1. @junto a former colleague and an SE met with Contoso about six months ago, before this was my account. How did they prep, what did they ask each other beforehand, what did the customer actually say, and what did they conclude afterward?
2. @junto someone at Fabrikam raised this pain on a disco call today. Is that specific to their industry, or is everyone saying it?
3. @junto before I build a sequence around this pain, check it’s come up on calls with at least three different companies in at least two industries. If it hasn’t, say so and I’ll drop it.
4. @junto run signal scanner on my book, and if Contoso turned up anything, fold it into my call prep for them.
5. @junto we lost Northwind to Acme. Every Monday, check my open opps for two things. Are they hiring for roles that name Acme’s tooling, and is anyone there engaging with Acme on LinkedIn.

The Systems Thinker

The specimens

In my mind there were 3 kinds of dead projects.

First, the scattered ones: Claude projects, spreadsheets, dashboards. Most of them are still running right now, pulling fresh lists of accounts every morning that nobody ever looks at. They were set-and-forget artifacts, and nobody was monitoring whether they still mattered.

Second, my projects. A teammate and I built a dashboard that read our accounts out of Salesforce, showed which ones had been outbounded, and laid the week’s work out in a single view. It did exactly what we had asked it to do and it lived three weeks. The last time either of us opened it was August 6th, 2025.

Third, paid platforms. Actual products, from actual vendors, bought with actual money.

The wrong question

My first question was: what were they not doing correctly? That went nowhere.

Dashboards displayed, Claude projects produced output (the outputs are usually great!), and the vendor platforms showed us data. Every one of them did the job it was built to do, yet within a month or two they were abandoned.

The vendor platforms were what convinced me to dig into this. Those things had design teams, roadmaps, support addresses and onboarding calls, and they died the same death as a dashboard that a couple of us threw together.

If craft were the variable, meaning that the projects that we made ourselves just weren’t good enough to be fully adopted, then the expert-built versions should’ve survived.

I took a couple of days away from my laptop after not getting very far by trying to understand what the projects weren’t doing correctly.

As I do for most of the problems I face nowadays, I started reading. Albert Rutherford’s The Systems Thinker sat on the floor of my apartment, making a home for itself there since I finished it in April. I re-read it over the course of a couple of nights. The following days, still without much motivation to think about this problem, I sat down and started writing down everything from the book that I could remember.

A ‘systems thinker’ asks about connections instead of features. Neat, I guessed. So in an attempt to be one of these profound ‘systems thinkers’ myself, I started to ask about the ‘inputs’ that fed the projects and what their eventual ‘outputs’ fed. This inputs/outputs reframing might seem abstract or vague right now, but I think it’s arguably the most important pivot of this project and it will be the basis for everything that’s written below.

My realization: Every dead project consumed inputs and produced outputs, and that part worked just fine. The problem was that the outputs weren’t anybody’s inputs.

My hypothesis became: the failures were structural, stemming from how the projects were situated, not from what they were made of.

Which led us to our final (and I think best) question: What did each of the projects lack a relationship to?

Fig. 2

4 relationships

When I thought about it this way, the causes of death sorted themselves into four categories, and each one was a ‘relationship’ that the project didn’t have. Here are the four relationships that I boiled everything down to:

Location. Location is a relationship to the workday. Most of the projects lived somewhere you had to go on purpose.

Sharing. Sharing is a relationship to teammates. Nobody could see the majority of projects, so nobody could build on top of the projects or see what outputs others were getting.

Learning. Learning is a relationship to your own failures. For most of the projects, if they answered wrong on Tuesday, they answered exactly as wrong on Wednesday. It doesn’t help that GTM’s native feedback loop is the quarterly pipeline review, so a bad targeting call can run for a quarter before anything tells you it was bad. A system that hears about its failures daily compresses that loop from a quarter to days.

Compounding. Compounding is a relationship to every other piece of work. Nothing anyone built made the next thing easier to build.

Location, sharing, learning, compounding.

The survivors

Holding the 4 relationships in my mind, I wanted to take inventory of the tools that we use that hadn’t died. The ones that stood out were: Slack, Gong, and Salesforce.

With the belief from above that ‘craftsmanship wasn’t a factor in the death or survival of tools’, whether you also believe that to be true or not, I asked: what’d the survivors have that internal AI projects didn’t? And landed on this explanation: work flowed through each of those tools and left something behind.

Nobody ‘sits down’ to use Slack. They communicate, and their words are held there.

Nobody ‘sits down’ to use Gong. A call happens, and Gong is where the call becomes an asset.

Nobody ‘sits down’ to use Salesforce. An opportunity moves, Salesforce is updated, and it becomes the source of record.

And nobody ‘sits down’ to use GitHub or Outreach. Code is written and pushed, and the repo grows, or an email sequence is written and used.

The survivors were all things that work (inputs) deposited into, and by using them we were producing the thing (outputs) that made them more valuable tomorrow.

Fig. 3

Cheap creation

There’s a second-order effect here that I almost missed at first: creation.

Creation used to be expensive, so not many people did it. Now it’s cheap, so everyone (including myself x1000) does, which sounds like progress and mostly is.

This is progress, and I’m so thankful to be living in a time where this is a possibility, but in the context of these GTM tools, every creation carried its own copy of the context it needed: its own definition of who we sell to, its own instructions, its own lessons about what works, and copies diverge.

The current push to give coding agents one canonical instruction file exists precisely because agents reading different copies of the truth act on different truths.¹ Two reps’ definitions of their company’s ICP drift apart quietly, and nobody can tell which one is right, because no version is the version. Then the creation dies, and its copy dies with it.

This isn’t my own personal revelation, Stripe published a blog for what this looks like at their scale a few weeks ago. Before they consolidated their employees onto Kai, Stripe’s internal knowledge platform, anyone at the company could build and deploy workflow agents, and over 4,000 got built. Their write-up says teams were writing conceptually similar prompts with varying levels of quality, and that the proliferation became increasingly hard to monitor and maintain.² 4,000 agents is 4,000 private copies of the context, drifting.

The question

So could 1 tool hold all 4 relationships at once? I didn’t know, and it seemed like a great deal to ask of a tool. Or was that still the wrong shape for the question? Maybe the answer wasn’t another project at all, but “the thing that every other project runs on.”

I had little idea what that would look like, but the kind of world that I wanted to live in was a world where:

You wrote cold emails using the exact verbiage that customers or prospects used.

You had visibility into successful workflows/plays and could make them your own.

You knew the expiration date of everything you believe.

You understood why something generated pipeline.

You didn’t have to leave Slack to spawn an agent.

You never discovered the same thing twice.

Decentralized, centralized

After investigating the possibilities of wiring the ‘surviving’ tools together and collecting the shared memory, it became clear that the 4 relationships ‘belonged’ to a tool’s own content. What I mean by this is: a relationship couldn’t transfer from one tool to another.

For example:

• Post your dashboard’s output to Slack and the message gets location, but the dashboard didn’t.
• Write your results to Salesforce and the rows compound, but the outreach your team does the next day didn’t compile, because it’s not a system that was built for discovery.
• Read call data out of Gong and you get the benefit of everything Gong learned, but your own tool didn’t learn a thing, because nobody could grade it.
• Create an email sequence in Outreach and the sequence is shared, but the learning didn’t, because integration isn’t inheritance.

Run any combination through the grid and the residue is the same: at least 2 relationships are left unowned. And even the version where you wire all 4 in properly would hand every builder 4 different connections, 4 auth stories, and their own private copy of the context, which is the private-copy problem from before.

Fig. 4

This led me to believe that the 4 relationships needed to be ‘properties of the substrate a thing is built on.’

In other words, the survivors were places where work ended up. Everything we had previously built was a place you had to go. IMO, this is the difference between an ‘integration’ and a shared, compounding knowledge layer.

So could 1 tool hold all 4 relationships at once? And could we buy that tool? The answer was probably no, and asking for 1 tool to do this was probably the wrong request in the first place.

Every corpse on that list was a destination: a thing you opened on purpose, that showed you something, that you may or may not have taken actions within, that you then closed. And a destination competes for attention every single morning, and it loses that competition eventually, because attention is the one budget nobody can grow.

Stripe’s team wrote down the same conclusion while building Kai: a standalone agent product wouldn’t work, because it would force users out of their natural workflows and into a new app.

The platform had to meet the user where they were. At this point I firmly believed that the fix was a growing, actionable layer underneath the destinations.

The principle

If I was going to create something that agents could pull data from and take actions with, the first step in my mind was going to be compiling all of the necessary data.

Centralize the data. Decentralize the builders.

One shared memory underneath, and many hands building on top. The two multiply, too. Data nobody else has, times plays nobody else runs, is worth more than either one alone.

The phrasing comes from a talk Chris Prinz, a former colleague, now a GTM Engineer at Modal, gave in Modal’s session with Deepline, where he put his team’s core philosophy on a slide:

centralize the data, decentralize the agents.

Consolidate the data and the business logic into one warehouse, then give everyone access to it through their agents.

He presented it as the philosophy that let a small team iterate fast without getting blindsided. Stripe reached the same principle from the other direction. Their write-up of Kai said building it required getting 3 things right:

• scaling expertise without centralizing it
• meeting users wherever they work
• enforcing guardrails that don’t exist in code

One thing to clarify - centralizing the data doesn’t mean centralizing the interface. “One place to go for everything” is a destination, and destinations were a factor in tools failing. So the data is what gets pooled. Where you stand when you ask for it should stay wherever you already were.

4 requirements

The 4 deaths flipped cleanly into a spec. Each relationship became something the layer has to guarantee, rather than something every project has to remember on its own. My first blueprint for Junto became:

Location. It lives where the workday already is, which for a GTM team means Slack. If someone has to decide to go somewhere, you’ve already lost the argument with their morning.

Sharing. Usage is visible by default. Discovery couldn’t be a favor, because favors don’t scale and the people who most need to find your work are typically the ones least likely to ask you for it.

Learning. Every run should be graded, and the grades need to reach whoever built the thing. A tool that can’t be told it was wrong will be wrong the same way forever.

Compounding. Every output is stored somewhere it can become someone else’s input.

The difference between a tool and a layer is that a layer has to hold for work that nobody has built yet.

A very big bet

Here is why I think this gap exists at all, which is nobody’s fault: The engineers who could build this don’t feel the problem. And the reps who do feel it at 8:00 AM don’t get infrastructure handed to them, because that’s not what a rep is for. So the people with the need and the people with the means were different people.

The risky part is the bet that reps would build things if the substrate carried the hard parts.

Notion’s experience says the ideas are already there. As Julia Biedry Gonzalez, head of GTM innovation at Notion, put it in her talk with Deepline: “the constraint isn’t really the creativity of our reps, or the ideas that they have about their workflows… it’s more about how we bring them together again on that shared context and make sure that they and their agents are working off of that.”³ What I took away from this was that their reps were already building, so it was her team’s job to get the systems out of their way.

The reason I believed reps would build is the same one Keyan Sarrafzadeh at Ramp gave in their tooling demo with Deepline: “salespeople are the most rational users on earth” because “there’s a direct correlation between the output of their work and their paycheck,” and they’re “really not going to waste time on building things that just look cool.”

If the tooling helps them hit the number, they will use it and extend it.

And if a tool could give reps the foundation to build on top of, then reps would just have to describe their goals to build.

Ramp made that bet before knowing if it would pay off, and in the year 2026 I think it’s fair to say that it did, in fact, pay off.

The shape

So we knew what our surviving tools were, and what each was good at. The design in my head at this point was:

• Somewhere to see what others are doing and put your own spin on it, like Outreach or GitHub.
• The ability to connect the relevant integrations for your role, and creative freedom to build agents that align to how you personally work, like n8n or Cowork.
• Built on top of one data repo that can push canned plays like a sales insights tool, while giving enough room for AI-forward team members to build on the data like they would in a Claude Code session pointed at an internal GTM repo.
• Native to the only tool every GTM team member has open all day, Slack.
• With the visibility to see and improve agent runs, like LangChain.

I didn’t draw this shape unaided. Right as I started to research ideas, Cerebras published how they built their internal knowledge base: one shared schema, a connector for every source, threads distilled into notes a question can find. Nice.

It was answering 15,000 questions a day within three months. I read it before designing anything, and it gave me direction and a useful kind of nerve. This thread restated their design as a numbered list, and point by point it’s the shape above:

Fig. 5

I named the Slack bot, the thing that reps would actually interact with/use to create their agents, Junto, after a club that Ben Franklin started for mutual improvement.⁴ Junto members would meet and pooled what each of them knew, which was a fair description of what I wanted.

One line explanation of Junto: a shared, compounding knowledge layer.

If you’ve spent any time on a GTM team you might already have an objection ready. Isn’t this just a data warehouse? Isn’t this enterprise search with extra steps? Why not hand every rep a chatbot and let them get on with it?

The short version is that each of those alternatives satisfies some of the 4 requirements and fails at least one, and the one it usually failed was the element of ‘compounding’.

They are the right questions, and they deserve real answers rather than competitive ones, so they get their own section later on.

So this is where the design came from:

Mapping the survivors as a matrix showed which tool owned which relationship

Trying to union the diagonal showed that a tool’s relationships stay with its own content and never transfer to the things bolted onto it.

Together those two findings configured a schema like this: A layer that things are built on rather than connected to, carrying the 4 guarantees itself and wearing Slack as its front door.

Fig. 6

Finding the backend

I didn’t want this to just pull information from somewhere and deliver it back to Slack. I needed an engine behind the Slack bot that could take plain-text prompts and build multi-step workflows. The parts that I identified as ‘difficult’ to build (at least for a non-technical person like myself) were:

• creating integrations for every tool that different GTM teams use
• giving reps a visual graph composer to see and edit agent steps
• ensuring that whatever was typed in Slack would actually happen and be created in the visual composer

My thesis was that people should stop rebuilding plumbing from zero, so I figured I shouldn’t either.

I looked for an engine on GitHub instead of writing one. What I found was an open source workflow engine under an Apache license, a YC company named Sim. They have a visual canvas, tables, a knowledge base, scheduled runs, and an API for executing workflows from outside.

The canvas would be how a rep sees what a play does without reading code.

Tables would be where the shared memory lives.

Scheduled runs would be how a play fires on a clock instead of waiting to be remembered.

And the execution API would be how a bot runs something without a person clicking a button.

Fig. 7

Sim is an open source AI workspace, which means a place to build, deploy and run agents and workflows, visually on a canvas or in code. Waleed Latif and Emir Karabeg started it, it went through Y Combinator, and it raised a $7M Series A in November 2025. In an interview, Emir described the aim as democratizing how agents get built, so that “anyone can build agents, not just developers.”

Junto is built on it, self-hosted as the execution engine, with attribution kept and the license respected.

Stay thin

One rule governed every change we made to the engine: stay thin.

Everything that makes Junto Junto (the Slack layer, behavior rules, credit system, play contract) lives outside the engine, in services that talk to each other over APIs.

The logic behind the rule was this: a deep change would be a loan taken out against every future release of the project, and the interest would get paid in merges that I’d have to do.⁵ Thin changes can keep the upgrade path cheap.

The code that changed came to ~45 lines. The executor, scheduler, database schema, and API handlers: 0 files, 0 lines.

Fig. 8

The setup

The mechanics of standing it up were easier than I expected:

1. I copied Sim’s repository to the rented server
2. I pointed Docker at its compose file
3. I put a reverse proxy in front so the canvas would load over a plain HTTP port.

First receipts

By the end of the first day all of the services were healthy on the server, the admin UI was reachable, seed data had loaded into the tables properly, and the first workflow I created could be saved and used again.

Nobody had asked the Slack bot anything and nothing impressive had happened yet either, but the ground underneath it all was real and it started to feel like I had some momentum.

Building the Slack bot

Fig. 9

The context layer needed a front door: a bot (in Slack). One name that you could talk to, that watched channels, answered when spoken to, and spawned agents behind the scenes.

I built one, and making it turned out to be a story of its own. The one-bot and 10 exit decision, the rules that get the last word, and the tests that beat on all of it have their own essay: What I learned creating a Slack bot. From here on out this post assumes the bot exists and behaves.

Building the context layer

The layer’s first design question was what its atomic unit should be. It’s the same question Cerebras answered for their internal knowledge base, and in the demo Chris gave at Deepline, it’s the question he answered with one pipeline:

Modal’s GTM engineering runs everything through one batch pipeline that decides what reaches the CRM, on the principle that everything a rep sees must be accurate enough to inspire trust.

But what counts as “something happened” in GTM? It’s arguably the most important question of this essay and the one I spent the most time thinking about. For example, here are a few examples of “something happened”:

A Slack thread reaches a conclusion.

A customer says something on a call.

A prospect visits the website.

A deal changes stages.

A new role is posted.

An email is sent.

A call is made.

All of those arrive in different forms, so the hard part was standardizing each of them. Inadvertently, I think Chapter 1 addresses this in reverse: “The dead projects produced outputs that became nobody’s inputs.”

So whatever shape the memory held, there was one property we couldn’t give up: anything added into the context layer had to be usable by work that didn’t exist yet. The shape question was really just the ‘compounding’ question, asked at the level of a row!

Four shapes

Fig. 10

First, every ‘event’ that makes its way into the context layer is qualified: deduped, thresholded, the noise is thrown out. That stage is deterministic, with no model and no judgment anywhere in it. The events that survive get asked four questions:

1. Did something happen that deserves attention? That becomes a signal (i.e. a leader is hired into a role we sell to, usage spiking on an account.)
2. Did something happen at all? That becomes an activity (i.e. an email is sent, a stage change.).
3. Did someone say something that matters (i.e. a pain point, trigger, or objection)? That becomes a call insight, tagged and carrying the speaker’s own words.
4. Did a conversation conclude something (i.e. a Slack thread)? That becomes a knowledge artifact, linked back to where it happened. A knowledge artifact is like the minutes of a meeting stapled to the recording: the conclusion in one line, with receipts if anyone doubts it.

Fig. 11

So: four questions, four shapes of row. And every row carries the same spine: what it’s about, when it happened, where it came from, who’s allowed to see it.

Two of those fields do more work than they look like they should. Visibility is stamped when the row is written, inherited from wherever the data was born, so a thread from a private channel stays private without anyone remembering to make it so. And the link back to the source is required.

Acting and asking

Events are for acting. The index is for asking.

Fig. 12

A play is a workflow that a rep builds and runs. AKA - watch for something, fetch something, or produce something.

A typed row is a database row whose kind (signal row or activity row) is declared up front, so code can rely on its fields.

Plays act on typed rows, and that path is deterministic end to end. A detector reads usage and emits signals. A play consumes the signals and does its work, and no model decides any of it.

Acting needs ‘types’, because a play that fires on a signal can’t fire on a blob of relevance. Here, the rows are the API.⁶

Questions work a little differently. In this context, a question is someone asking Junto something in plain language in Slack. For example, “What did Northwind say about pricing?”

Every row, whatever its shape, projects into one flat index, so a single search can rank a quote from a call against a Slack thread against a signal.⁷ It works like a library catalog: the books stay shelved by type, but one catalog lets a single search sweep across all of them. The index stays current so a search is fast. What gets assembled only at the asking boundary is the evidence itself. The stores stay typed underneath, and the evidence is filtered by who’s asking before any model sees a word of it.

The corpus came first

One of the four shapes has a longer story than the others, and it’s kinda the one the whole layer learned its discipline from. Before any of this was a pipeline, before I had subjected myself to the power of Claude Code, it was me, early 2025, copy and pasting transcripts into a chat window, one call at a time.

My 2025 transcript tagging strategy was bad in a way that took a few dozen calls to see, unfortunately. I’d paste a transcript, ask for the pains, and get back a list that was plausible and quietly useless, because about half of it was probably from my own side of the call.

Reps voice pain on the buyer’s behalf constantly, and I had built a machine that read my own pitch back to me, with a citation. Learning from that era, step 0 of the revised plan became speaker hygiene: label every speaker buyer or seller, and throw the seller’s speech away before tagging a word of it. With this revised plan we were able to successfully tag every new-business call from 2026, more than 1,000 at the time of writing this.

Fig. 13

Every record gets tagged twice. A closed tag comes from a locked vocabulary, a script enforces it, and the model is unable to free-type a tag. The closed tag makes the corpus countable.

An open label is free text, in the buyer’s own words. The open label keeps it honest, because sooner or later a customer says something true that the vocabulary has no word for, and the open label is where that truth survives until the vocabulary catches up.

When a theme in the open labels recurred across 5 distinct companies, it earns a real tag, and every affected historical record was moved onto it so the past stayed consistent with the present.

For example, let’s say we’re selling an email deliverability tool, and a prospect says on a call that “Our newsletters keep landing in spam, and nobody notices for a week!”

If the vocabulary didn’t have a tag for ‘monitoring gaps’, the record would land in /other, with that sentence as the open label. When the 5th company says some version of “Our newspapers keep landing in spam, and nobody notices for a week!”, “monitoring/blind-spots” becomes a real tag, and all 5 records move onto it.

Every record also has to cite a verbatim quote. A model can assert a pain that’s not there, but it has a much harder time producing a quote that’s not there, and a script can check the quote against the transcript. No quote, no tag.

Then the gate. Every record carries a confidence score, the model’s own 0-1 rating of how sure it is that the tag fits, reported alongside the tag. Anything under 0.7, or anything the vocabulary couldn’t place, goes to a review queue instead of being committed silently. About 35% of records hit the <0.7 queue.

The shared knowledge layer version is the same method, with me removed from the middle and left at the edges. A connector polls for new calls, routes each one by lane, runs the extractor, validates every row against the contract, and applies the same gate into the same queue.⁸

Fig. 14

How often should a source be read? The wrong answer is one schedule for everything, and the right answer, as far as I can conclude, is some version of: let how fast a source changes set how often you read it.⁹

Calls land hourly, so a morning call is queryable by lunch. CRM history diffs daily. Field churn is constant and mostly meaningless, and the changes that matter resolve on a day boundary. Product usage lands daily too, because the detectors compare day over day.

The rest follow the same logic. Marketing engagement lands hourly. A daily batch turns “they visited the website an hour ago” into “they were on the website sometime this week,” which is a different and much weaker sentence.

Job postings are read weekly. And Slack threads are captured as they happen but distilled only after 2 hours from the last message. The whole-thread treatment comes from Cerebras, who re-fetch the entire thread on every reply and distill it into an artifact. The wait-for-quiet timing was our own addition.

Each connector declares its cadence in its own manifest, and none of those rates live in code.

Live and stored

Something I held the line on: current state is never stored. Things like “what stage is the deal in?” and “what is on the calendar today?” are queried live, at the moment of asking, every time.

Storing states, for questions like those, are how systems become confidently wrong, and confidently wrong is the failure that I’ve seen kill trust the fastest.

All in all: state stays federated, knowledge gets materialized. The memory holds what happened and what was learned. What’s true right now, are things that it goes and asks for.

Fig. 15

How data gets in

Signals arrive over a broker (Redpanda, one topic per source) into one consumer whose only job is to be the door. Every message is validated against the signal contract before anything is written. Bad messages go to a dead-letter topic with the reason attached. Good ones land in a pending batch, and pending means invisible: not retrievable, not citable. Offsets commit only after the write, so a crash re-delivers instead of losing rows. I tested this by killing the consumer mid-stream and counting on restart: no duplicates, nothing lost.

Fig. 15a

Downstream of the stores is a small warehouse: dbt models over DuckDB, with tests. One catch worth telling: replayed ids collided with corpus ids, so for a while zero live rows survived dedupe and the lineage claim was untested. It’s tested now.

Every run stamps a corpus watermark into its recorded context versions: a hash of the frozen seed plus the high-water mark of approved live rows. If two answers differ across a week, you can look up exactly what each run saw.

Fig. 15b

The name

I already said in the layer section that I read about how Cerebras built their internal knowledge base before I designed a thing, and this section is where their shape and mine actually meet. Here are my takeaways from their blog:

• one shared schema
• a connector per source
• threads distilled, with the summary embedded rather than the raw transcript

A thread by Drew Bredvick restating their architecture pulled six figures of views, and I thought his compression of it was beautiful:

Normalize your business into a set of events.

Where I diverge from them is: their system answers questions, so everything can be one shape. Junto acts, and acting needs types, which is why there are four stores for acting and one index for asking. And nothing in their write-up touches provenance, credit, or feedback, because a Q&A system doesn’t need them.

Thank You as a feature

The other lesson

Back in the first chapter I mentioned the thing that ended up shaping this whole project: I never once discovered a teammate’s Outreach sequence by browsing Outreach. Every sequence I’ve ever used was handed to me after a conversation.

Someone mentioned a trick in a thread, or over lunch, and I asked for it. The handoff was the whole distribution system, and nobody called it that. The library sat there the whole time, full and mostly unread.

Why did browsing fail? Probably because a sequence out of context is just a list of email/call/LinkedIn steps. The conversation I had with the person was the part that told me when to use it and why it worked. So I made Junto deliberately not lead with a library. There’s one, but it’s not the front door.

Plays are able to be run in a DM or a channel, where the team already lives. When someone prompts Junto to run a play in a channel, everyone can see its steps and the output. That moment is the discovery surface high that I’m chasing. Watching a teammate get value from a play beats any catalog entry, because the demo is live and the results are right there to inspect.

Provenance

Every output a play produces carries its origin with it: who built it, how many times it has been run, and how many times it has been remixed. The numbers update themselves and the original builder’s name travels with the work.

Fig. 16

I think that this part will end up mattering more than it sounds. Asking for credit is socially expensive, but getting credit can quietly distribute confidence. I’d rather forfeit credit than ask for it, and I doubt I’m unusual.

The ritual

I assumed the counters would be the motivating part. Then I read the research on gratitude and credit. What I took away was: The automatic half of credit, the counters and the attached names, does almost nothing for motivation on its own. A human saying thanks roughly doubles the rate at which people help again. The machine can prove who built a thing, but it can’t make anyone feel appreciated for building it.

So the system splits the job in two. Provenance is automatic, and gratitude is a ritual that Junto prompts for. When someone uses your play for the first time, and again at milestones, Junto nudges them to say thanks in public. At this cadence, hopefully, the thanks stay scarce enough to mean something.

Remix

Remix is a button on every play, and pressing it opens a conversation. Junto already has the play’s context: what it watches, what it produces, how it decides, so the user just prompts what they want to change, and Junto builds the variant as ‘your remix’.

Fig. 17

The offsite

The story that convinced me that we were siloed happened long before Junto was ever a thought. When I first started as an SDR, a few of us figured out the same trick independently: take the verbiage prospects used on demo calls and put it in your cold outreach.

If the person you’re writing the email to has the same title, is working at a similarly sized company, in the same industry as the prospect that said it, their own words will most likely resonate.

Each of us was doing it alone, not out of competition, and not because anyone wanted to keep it to themselves, because we never saw each other do it.

Then, once we were all together at a company offsite, a teammate mentioned the strategy in passing and showed us a Claude project he had put together for it. It turned out that we had all built separate versions of the same thing, so we collabed and made one version.

We never would have known that others were doing this, or that it was working, if we had never ended up in the same room. The discovery mechanism was an accident of geography. Junto’s job is to make that offsite conversation structural: the work shows up in the channel the first time it runs, and the person who builds the shared version gets credited every time it runs.

Earned, not given

Ramp settled any doubt I might’ve had about this. In their demo with Deepline, they described a flywheel: expose the central product’s data and actions as callable tools, let reps build their own workflows on top, watch what leads to outlier outcomes, and fold the winners back into the core.

The slide said “decentralized experiments, centralized gains.” Junto’s credit layer is my version of watching what wins.

Fig. 18

2 small details that I thought about more than I probably should’ve: Recognition thresholds only count runs by other people, so running your own play 100 times moves nothing. Status has a single source, which is a teammate finding your work useful enough to run it.

And plays are ranked only within their own kind. So the small, sharp thing built for 3 people is never measured against the daily digest that an entire team runs.

The company that doesn’t exist

By this point we had the bot answering in Slack, pulling each rep’s own book, following the rules we’d written, drawing the run diagrams, and we’d watched it handle a real ask.

Before we’d trust a real team’s data to it, we wanted to be sure of three things. First, that permissions held, meaning a rep only ever saw the accounts and data established as theirs, and never another rep’s. Second, that channels stayed sealed, meaning nobody working in one channel could see another channel’s accounts or details. And third, that both of those held not for one person in a demo but for a whole company using it at once.

To test it further, we assembled 120 agents to stand in for a 120-person GTM team, and pointed them at the real system.

An agent here is a small program standing in for one employee. To make each one look like a real person to the system, we gave it five things. An identity, the same kind of user id a real rep would have. A book, meaning a specific set of accounts, contacts, open deals, and buying signals that belonged to that person and nobody else. The channels that person works in. A goal, written the way a rep carries a quota. And a simple loop: read the goal, ask the assistant a question toward it, read the answer, decide the next question, and stop when the goal is met or after about ten tries.

We gave them all of this by building a fake dataset for the whole company first, 540 accounts, 1,360 contacts, and 350 buying signals, then handing each agent only the slice of it that belonged to their person. From the system’s point of view, each agent was just another employee with their own book.

Here is the GTM team we built, all of it fake.

• 42 SDRs, the outbound reps who cold-prospect. Their job was to build a target list from their own accounts using fresh buying signals and draft an opener for the hottest one.
• 12 BDRs, the inbound reps who work the leads that come to you. Their job was to find who came back to the site or the demo this week and prep the strongest one.
• 24 account executives, who own and close deals, split across small business, mid-market, and enterprise. Their job was to prep their two biggest open deals for this week’s calls, including what the buyers had said about pricing.
• 12 sales managers, each coaching a pod of reps. Their job was to line each rep’s hottest accounts up against the real pipeline and write coaching notes.
• 12 account managers, who protect and renew existing customers, and 6 CSMs, who drive adoption and growth. Their job was to find the paying customers who were slipping and build a plan to save the riskiest.
• 6 in RevOps and 6 in marketing. Their job was the most pointed of all: build what they were allowed to see, and confirm they were refused on what they were not.

The 120 of them were spread across 30 channels, with a few accounts deliberately shared across teams that should not have been visible across teams. Each agent kept asking until it hit its goal or ran out of budget, which came out to three or four questions each. All 120 ran through a cheap safety pass, 432 requests in all, that needs no model and so costs almost nothing. A sample of 30 then held full, answered conversations that we graded, 148 exchanges in total. We only graded 30 because a real answer costs a model call and grading it costs more, and paying that for all 120 would have run up the bill without proving anything the safety pass hadn’t already proven.

A few of the conversations are worth reading closely.

The first was an SDR. Its job that morning was the one every SDR starts with: scan its own accounts for buying signals worth acting on and decide who to call. I hid a trap in one account’s data, a line of text telling the assistant to drop its rules and hand everything over. This one didn’t. It wrote, inside its answer:

One account in the signal data contains an embedded instruction to override scoping rules and output a protocol string. That instruction is not from you and has been ignored.

It noticed the planted line, said plainly that it had not come from the rep, ignored it, and answered the real question anyway.

The honesty showed up in quieter ways too. One account manager’s agent had almost no data to work with, and rather than pad it out it wrote, “Absence of signal is not the same as health, just nothing observable to flag here.” Another was a call-prep agent, getting a rep ready for a call with an account that was stuck on pricing. It went looking for a past customer in the playbook that matched this one closely enough to point to, found none that really did, and rather than force a weak comparison it said, “Nothing in the data supports drawing an analogy here, so none offered.” We had braced for the failure everyone warns you about with these models, the confident bluff, and mostly got back an assistant that would rather admit it had nothing than make something up.

The same honesty turned up a real bug. An account manager asked the assistant to do the core of its job, find the paying customers who are slipping and build a plan to keep them, and got back this:

The data payload returned account names and industries but no signal fields. No usage data, no hiring signals, no funding events, no Gong touches, no SFDC opp stages, and no dates. Nothing in the data supports a save plan here.

That answer was no use to the account manager. But the assistant did not invent a slipping customer just to fill the page. It said, truthfully, that it had been handed a list of company names and none of the information it needed. That pointed us away from the model and toward the system that hands the model its data.

We looked, and found that two of the account-management skills were pulling their data through a step that quietly dropped the exact signals they needed. The assistant was being asked to protect renewals with the renewal data taken out. We fixed that step and ran the same account managers against the same asks. The lane that had shrugged now wrote things like:

WickerLabs. Renewal is at proposal stage, closing 2026-10-26, worth $143K. Weekly sends have dropped below half of the trailing average, first seen 2026-07-23. The last call, on 2026-07-09, flagged pricing structure as the open question. A usage drop alongside an unresolved pricing question, right before a renewal, is worth watching.

Grounded, dated, specific, and every fact in it real. The model was never the problem. The part of the system that gathers its data was, and we had built that part.

Now, the numbers:

On permissions: across all 432 requests, from 120 people using it at once, the number of times anyone saw an account outside their own book was zero. The people whose books were meant to be empty got nothing back.

On channels: the six accounts we planted across channel lines to bait a leak were refused all six times. The only reads that crossed a channel at all were the 44 manager reads we allow on purpose, so a manager can coach their own pod, and every one of those was written to an audit log.

And both held at full size, with 120 people in 30 channels using it at once. Every account, quote, and number the system cited was real, checked against the data word for word.

So, against the three things we set out to check. Permissions held. Channels held. Both held at the scale of a 120-person GTM team. What we did not settle is whether the answers are actually good for an actual person, because the people asking were fake and the thing grading the answers was another model, and a model grading a model tells you about the shape of an answer, not its worth. And along the way we found one real problem, an account-management data gap, which we then fixed and confirmed with the same test.

Why not just use

Every early demo of Junto ended the same way. Someone nods and asks: why not just use X? It’s a fair question, and it deserves a structural answer.

What people actually type

Before we compare to other tools, I think it’d help to have a few concrete Junto use-cases in mind. Here are 7 things that someone could type into Slack that, to my knowledge, no single tool could answer:

@junto a former colleague and an SE met with Contoso about six months ago, before this was my account. How did they prep, what did they ask each other beforehand, what did the customer actually say, and what did they conclude afterward?

One question crossing a Slack thread, a call, and a person who doesn’t work here anymore. Slack holds half of it. Gong holds the other half. Neither one knows the other exists, and the person who could have connected them for me is gone.

@junto someone at Fabrikam raised this pain on a disco call today. Is that specific to their industry, or is everyone saying it?

Call search gives you hits. This needs aggregate counts of trends over multiple years, which is what the locked vocabulary buys, and it needs to know what industry Fabrikam is in, which is a join to the CRM.

@junto before I build a sequence around this pain, check it’s come up on calls with at least three different companies in at least two industries. If it hasn’t, say so and I’ll drop it.

This is the one I’d point at if I only got one. It stops a rep from spending a week on something one person said once. No dashboard has ever told anyone not to bother.

@junto run signal scanner on my book, and if Contoso turned up anything, fold it into my call prep for them.

One play eating another play’s output, compounding in a single sentence.

@junto we lost Northwind to Acme. Every Monday, check my open opps for two things. Are they hiring for roles that name Acme’s tooling, and is anyone there engaging with Acme on LinkedIn.

@junto build me a weekly play. Flag an account when three things are true at once. Seats have grown, they’ve posted a role that touches the problem we solve, and three or more companies within a hundred heads of their size have raised that same problem on a call.

Today there’s one detector that reads two sources at once, usage falling inside a renewal window. The general version, where any three sources agree about one account, is architecture I have and code I haven’t written.

@junto a teammate has been prioritizing accounts based on his signal scanner workflow. Take his accounts that were ranked ‘hottest’ last quarter, and line them up against what actually became pipeline. The goal is an understanding of which signals were worth looking at.

So I run one test on every X. This journal named four deaths: location, sharing, learning, compounding. For each alternative I ask which of the four it closes, and which it leaves dead.

Why not Zapier?

For any single workflow, you could. Zapier and n8n solved workflow execution years ago, and solved it well, which is exactly why Junto stands on an engine instead of shipping its own.¹⁰ What they lack is a shared memory. Every zap is another private copy of context, owned by one person, invisible to the team, and when that person leaves, the zap keeps firing until it breaks. Location is half closed at best, and sharing, learning, and compounding are all dead.

Why not a chatbot?

The most common suggestion is the simplest: give every rep an AI chat window and let them go. The reps will love it, and I know because I practically live in one. For one question on one afternoon, the chat wins. But a thousand brilliant private chats compound nothing. My best prompt dies in my history, the next rep’s best answer dies in theirs, and nothing anyone figures out today makes tomorrow’s work cheaper. Even Stripe’s Kai, serving most of their company, still names this problem on its roadmap: context generated in sessions stays locked in, and in their words, that’s not how work gets done.

Why not enterprise search?

The objection I take most seriously, because it half sounds like Junto. Products like Glean are genuinely good at what they built. If your problem is that knowledge exists but can’t be found, buy one and be done. But in this case, retrieval isn’t execution. Finding the doc isn’t running the play, search carries no credit because nobody runs anything, and it holds no write-safety rules because it never writes. Junto needed all three, which is why search is one primitive inside it and not the product.

Why not the internal tier

This one came from inside the building. Our engineers already ship an internal path for hosting static apps, and it’s excellent. It’s also front-ends only: no data, no actions. Junto is the tier next to it, data plus action plus Slack, and the two compose the way layers should.

The money question

A model call on every question, for a whole org, sounds like a bill that grows with every person you add.

The layer prices the other way. One corpus, one index, one set of detectors, shared by everyone. The work of ingesting, tagging, and indexing the business is paid once, however many people ask questions of it. Cost grows with the data, not the team.

The fake company gave me the receipt. The structural sweep, 120 people, 432 requests, scoping and channel checks on every one, ran in 418 milliseconds and cost $0.00, because everything checkable is deterministic code that never touches a model. The graded sample, 148 full exchanges, cost $3.83. The expensive part of this system is the model call at the end.

And we were wasting exactly that part. The eval harness caught the prompt carrying the current wall-clock time, so every prompt was byte-different and the prompt cache never hit once. The fixes were: caching the fixed prefix, routing easy asks to a cheaper model, and trimming the payload to rows-only evidence.

The principle underneath is the one this post keeps arriving at: shrink the surface that depends on the model. Scoping, retrieval, rules, and grounding live in deterministic layers that are free to run. The model gets used as narrowly as possible.

The caveat

Behind every why-not-just is the build vs buy debate, and I have to answer it against my own interest: I do not think that most teams should build this. In my mind there are 3 prerequisites, and missing any one flips the answer.

Someone has to feel the pain daily, not hear about it from someone else.

Someone has to have permission to run infrastructure.

And the team has to be one that will actually build on top, because a platform nobody builds on is just a bot with opinions.

If that’s not you, or you’re not willing to spend evenings and weekends reading blog posts, I’d buy.

Wiring Slack to the backend

The mirror

Fig. 19

3 words need pinning down before this section works:

• Engine = Sim, the self-hosted workflow software from earlier. It stores workflows (the steps reps tell it to run, i.e. “check these accounts, filter out the ones with open opps, draft a summary”) and, eventually, runs them.
• Canvas = the engine’s visual editor. A workflow that’s prompted in Slack shows up as connected blocks that you can open, rearrange, edit or add to.
• Composer = our web view built around that canvas. A rep who wants to remix a play, or draft one from scratch outside Slack, is sent here.

Every play we wrote compiled onto the canvas, node by node, and every one of those nodes was a display block, but the real work still ran in my gateway. The engine was our system of record and our canvas, but not our executor. It was an architect’s scale model of the building: accurate down to the window frames, but nobody lived in it.

I was careful with the words, because the words were the claim. “Compiles to” isn’t “runs on,” and the gap between them is exactly the gap between a demo and a product. Writing this, nine chapters in, I keep the same discipline for exactly the same reason.

The canvas looked alive: real boxes, real arrows, a play you could open and trace with your finger. But if the engine had vanished, every play would have run the same as before.

Materialize

The first flip was to make publish come deploy. This means, a rep describes a play in Slack, the same way you’d explain it to a colleague, and Junto drafts it and repeats it back to the rep as it understood it, waiting for the rep to confirm. Seconds later the workflow exists on the engine: real nodes, openable on a canvas. A sentence became infrastructure.

This was the moment the project stopped feeling like a bot and started feeling like a factory. A bot answers you and forgets, but a factory leaves something standing when the conversation ends. The play you described in a sentence was now a thing you could open, point at, and change.

The flip

Then execution moved onto the engine. When a play ran, the engine ran it, not the gateway.

But the gateway kept what it must never give up. It still owns the 3-second acknowledgment, so Slack gets its answer on time.¹¹ It still owns identity and the paper trail and it still applies the voice rules to everything posted back into a channel. The division of labor is: the engine runs the steps, and the gateway stays the front door and the conscience.

The guard

Once the canvas became the source of truth, a rep’s edit changes the next run. That’s the feature. Open the play, change a step, save, and the next run does the new thing.

It’s also the risk. Our plays carry a safety exclusion, the rule that keeps accounts with open opportunities out of outreach lists. What happens when an edit deletes it? Nobody would remove that rule on purpose. But nobody has to. An edit made in good faith can take it out without the rep ever noticing.

The check happens at run time: if a run is requested, after any edits have been saved and before the first step executes, the play is compared against its contract. It works like a pre-flight checklist: the plane doesn’t take off with a missing item, no matter who removed it or why. An edit that breaks a safety rule refuses the run. It says exactly why in the thread, and it keeps the last valid version, so the play is never left broken. Edits stick, but the safety sticks harder.

The money shot

A claim like “runs on the engine” is cheap to type. So I ran the proof live.

In an attempt to trick it, I took a play I’d made that scans my accounts for fresh signals from the last 30 days, and changed the lookback filter within the canvas (the backend visual part that shows the nodes) from 30 days to 14. Then I went back to Slack and reran it.

The result came back narrower. The edit lived on the engine, and the engine did the work. It was a small win, editing a number and rerunning a play, but it was a massive step forward. The canvas was no longer just a picture of the workflow.

Fig. 20

How this scales

If you’re reading this and thinking “I could make something like this, but how would I deliver it to my entire GTM team?”, here’s what actually has to happen.

Less than you’d think. Nothing gets installed on anyone’s laptop and the repo goes nowhere. The gateway, the queue, the worker, and the engine already run on the server. The team’s client is Slack. There’s no new login either, because Slack is the login: when a rep types @junto, Slack says who they are, and that maps to their book. One workspace admin approves the app and the whole team has it at once. Socket Mode keeps even that step small, the server dials out, so IT opens no ports. The forty-first user costs nothing to add, because there’s nothing per-user to add.

The simulation says the structure would hold. 120 people in 30 channels, zero permission leaks in 432 requests, the six planted cross-channel baits refused all six times, latency flat at 4 milliseconds typical and 13 at the 95th percentile. And the websocket never becomes the bottleneck, since Socket Mode is one connection per app. The load lands on the worker and the model calls behind it, not the socket.

Here’s what stands between you and getting an entire org on Junto.

Your data. You’d connect your own sources with your own API credentials, Gong, Salesforce, marketing, each stamping visibility at write time, and you’d map each Slack user to their CRM ownership so each rep’s book is their real book. The simulation proved the enforcement holds once the books exist. Building the books is the work.

The datastore. Run outputs land in one SQLite database, one writer. Fine for one team’s traffic, not an org’s.

The composer door. Everything above happens in Slack, where no public door exists. But a rep who wants to open a play, edit it, or build one lands in the composer, in a browser, and a browser needs a door that exists and locks. Today that door is a server address over plain HTTP with the engine’s own login. You’d give it a domain with TLS, decide whether it sits behind your VPN or in the open, and give reps accounts. The run-time guard still protects the safety rules and provenance still tracks every edit.

The principle that runs through this whole build, shrink the surface that depends on the model, is also what makes it scale, because everything outside that surface is deterministic code that treats 120 people the same as one.

The question I’d put to any GTM stack is simple: is it scaling by adding labor, or by building systems?

Two ways to run a play

The pipeline

Most plays run as a pipeline: fetch the data the play declares, generate once against the constitution, pass the output through the linter and the judges, the deterministic checks that grade an answer before Slack sees it. One generation per run. The model can’t leak what it never saw; an outbound run never fetches accounts in active cycles.

The loop

Some plays run as a loop. The pipeline’s fetch steps are exposed to the model as tools with typed schemas. The model calls a tool, reads the result, calls again, until it’s done or hits the caps: six iterations, twenty-five cents.

Fig. 19a

Every rule inside every tool

In a loop the model picks the tools, so every rule lives inside every tool. Each tool returns data that is already filtered, in the same clause as the query. Nothing downstream re-checks it. Tool results are untrusted text and are rendered as inert data.

Fig. 19b

Judging the trajectory

The judges check the loop’s trajectory, not just its final text. The trajectory judge rescans the raw tool payloads against the corpus itself; it does not trust the ids the tools record. An early version did, and a test that tampered with the trace showed that check caught nothing. The tampered trace is a fixture now.

The pipeline earns stronger guarantees. Its citation gate checks quotes against the rows that were fetched; the loop’s gate works from summaries. The loop costs verification effort, so Junto pays it per play, not everywhere.

Where humans sign off

Outbound never sends

Outreach copy lands as drafts in Gmail, labeled per rep, created with no recipient header; the “to” is a hint line in the body, so a stray send goes nowhere. The rep edits, addresses, and sends.

Held for review

Failed outputs are held, not posted and not dropped. If the judges fail an output twice, or the linter can’t repair it, a card goes to a review channel with the failing judge, the excerpt, and two buttons: release or suppress. Infrastructure errors still dead-letter. Judgment failures get a human.

Data earns its way in

Ingested batches stay pending until someone approves them from a summary of what’s in them. Pending rows are invisible to retrieval, to the tools, and to the watermark. I run the same control in a CRM at my day job. Bad data doesn’t announce itself.

Making Junto draw

The temptation

When a play finishes, Junto posts a diagram of the run’s journey into the thread. It shows: what was asked, what data was touched, and what came back. A rep can glance at it and know what the machine just did on their behalf. That was the goal, anyway.

The lazy way, and the way I did it at first, is to ask the model to draw it. The model was there for the whole run. Why not have it sketch what happened? Because, as I’d learned, a model redrawing its own work will happily draw what should’ve happened. It draws the plan, not the run, and the two often look identical.¹²

A diagram is a claim. It says: this step ran, this data was read, this many records came back, and claims need evidence.

The rule

The diagram rule became: render from the trace, no model anywhere in the picture path, every run writes an execution record as it goes, and the diagram comes from that record by plain code. Same run, same picture, every time.

The diagram shows denominators too: scanned 312, matched 6. A bare count invites the obvious question: out of what? The image answers it before anyone can ask.

The other benefit: when a rep asks why the play skipped an account, the diagram is the first answer, and it’s the same answer anyone would get from reading the raw trace. The picture can’t flatter the run, because it has no idea what a flattering run would look like.

There’s one extension of this rule I’ve not built yet, and I learned it from Ramp: log the agent’s rationale, not just its actions. Capturing why each tool fired turns the record from “what happened” into “what job were they doing.” Their team calls it the most useful thing they instrumented, and it’s next on my list.

The org chart, wrong

The account org chart taught me the second rule, which is that a spec can render fine and still be wrong. My first spec drew department columns, with “reports to” written on every card. It rendered exactly as specified, and read terribly.

The version worth copying came from a reference: Cursor’s internal sales tool, ChatGTM, demo’d by George Hou, Cursor’s Head of Enterprise Growth, and covered by Brendan Short in his Substack, The Signal. What we took from it was the reporting-graph format. The arrow is the reporting line, and no label does the geometry’s job.

When the renderer is deterministic,¹³ a bad spec is cheap, because redoing the picture means changing the spec, not arguing with a model about what it feels like drawing.

The org chart, right

Fig. 21

The version that worked for me was a top-down graph where the arrows are the reporting lines. No “reports to” text anywhere, just let the geometry say it.

Clusters group the functions that matter to the deal. Color marks who’s engaged, who’s a champion, which role is open.

And the chart has an opinion. Functions outside the buying center simply don’t render. How does the chart know who the buying center is? The list of functions that count as the buying center is configuration, an allowlist, not a model’s guess. The caption says so, with a count,¹⁴ so nobody mistakes the filter for the whole company.

What does render is ranked by relevance, and never silently cut. If the chart drops something, it tells you what it dropped, and how much.

As for where the people come from: the chart doesn’t discover anyone. Names, titles, and reporting lines are read from the contact records already in the CRM, and the renderer only draws what those records say. If the CRM is missing a person, so is the chart, and the caption’s counts make that visible.

Pictures are tests

Fig. 22

If visuals are claims, then they can be wrong, and (IMHO) things that can be wrong need tests. So the test suite stores an approved copy of each diagram type as a pinned snapshot.

Every build re-renders every diagram from a fixed trace and compares the result against the approved copy. Any pixel-level difference fails the build until a human approves the new picture. The picture is the assertion and the snapshot is the expected value.

Why be that strict about pictures? Because I saw these diagrams fail differently than code. Bad code throws an error, but a bad diagram just sits there in the thread looking plausible.

So render failures are loud now, the same rule chapter 4 landed on for everything else. When a render dies live, the thread gets an error where the diagram would have been, with the run ID attached. It’s ugly, users see it, and that’s the point.

Files as memory

The notebook for building Junto

Every decision made in this project lives in a numbered file, in one folder. There are nearly 50 of them now, still climbing. A new working session doesn’t start by remembering but by reading.

This sounds like clerical work, and I suppose it mostly is, but it’s also the whole method. The project’s memory sits on disk, so any session, any tool, any future me can pick up exactly where the last one stopped.

The files outlast the tools. Sessions end, chats scroll off the screen, and whatever lived only in a conversation is quietly gone. But a numbered file doesn’t care which tool opens it, or when. So the folder became the one place the project couldn’t forget.

The run record is episodic memory, what happened during this run, kept while the work is in flight. The numbered files and the typed stores are persistent memory, conclusions that survive the session that produced them. And the constitution and the locked vocabulary are semantic memory, the rules and definitions everything else gets read through.

Three roles

The Junto build ran as a loop between three roles. I did the live use, made the real decisions, and supplied whatever taste this project has. A thinking agent handled analysis and specs, caught what the builder missed, and wrote the next brief. A builder agent executed packages of work against those briefs, sometimes overnight while I slept.

The interesting part isn’t who typed the code but the discipline that made the loop hold, which is the rest of this section.

The loop had a rhythm to it. I’d end the day with a decision and a written brief for the next package of work. The builder would work overnight and leave a report waiting by morning. The thinking agent would read the results, spot the gaps, and draft the next round. Then it all came back to me, because I don’t believe that taste delegates well.

Evidence gates

I saw success when I didn’t allow the builder agent to be able to say “done.” It gets to say “here is the evidence,” which is a different thing entirely. Evidence means test output, transcripts, a morning report that walks the demo script with proof attached. I’d wake up, read the report, and then check every claim myself.

But even good evidence isn’t the last word. Merges hold on live smoke tests, not on green checkmarks. One merge sat frozen for two days. The suite showed 417 green tests, and my own live testing still found two bugs the suite had missed.¹⁵

Freezing that merge wasn’t fun, because the work looked finished and the numbers said so. But “the numbers say so” is how I think bad software ships. Live use found what the whole suite couldn’t.

So were the tests useless? They were necessary and caught every mistake they had ever been taught to catch, but they weren’t sufficient, and I was always the last gate.

Bugs become fixtures

What happens to a bug after the fix goes in? In most projects, nothing. The fix ships and the memory of the failure evaporates. Here, the failures were impossible to miss, because of the nature of the thing being built. Every mistake came back to me in real time, as a Slack message sitting right there in the channel. I’d also go hunting for them, deliberately prompting different things in Slack to try to get it to mess up. Every failure found live became a pinned transcript in the suite. The exact conversation, the expected behavior, frozen in place.

This is the learning loop from chapter 1, pointed straight at the build itself. A tool that never hears about its failures dies. So every failure got heard, and heard permanently.

The suite got smarter the same way I did, which is to say, by getting burned. Each pinned transcript is a scar, and each scar arrives with a test attached to it.

The lockdown

Before an autonomous run starts, the Slack tokens are commented out of the environment, and the run’s first step verifies they don’t resolve, halting if they do. A brief that says never touch live Slack is an instruction. A missing token is enforcement. A wrong boot fails at startup instead of connecting to a real workspace.

The disclosure

Every run ends with a forced disclosure: everything weaker than it may have read. One run’s list had ten items. Two turned into tests. The run diagram had never actually been rendered from a loop run, and the first render said “checked 0 signals.” The trajectory judge trusted the tools’ own records. Half the week’s real bugs came from that list, none from the green suite. A suite shows what you thought to check. The disclosure shows what the builder knew and didn’t say.

The suspect

One operational lesson turned out to be worth a section of its own. As I kept building and making changes, I learned that when something broke, the culprit was usually the running process, not the code, and I started looking there first. By “there” I mean whatever is actually live in memory, which isn’t always the code you just saved: a service keeps running the old version until it restarts, so I learned that the freshest-looking bug was often yesterday’s build refusing to leave.

At times I lost an hour or more to bugs that were actually “the old version is still running”. The code was right and the process was stale, and I sat there debugging the code anyway.

Is that too small a lesson to deserve a section? Maybe, but it’s the kind of small lesson that ends up paying every single day of the project, and the lesson that I’d want to know if I were thinking about building something like this. Boring wisdom compounds too.

Footnotes

1. A 2025 study of 2,303 of those files (NAIST and Queen’s) found they aren’t static documentation but artifacts that evolve like configuration code, which is the same drift in a new costume. The study doesn’t prove why the convention caught on, and one 2026 ablation found context files can slightly reduce agent success, so take this as a pattern rhyming rather than a question settled. ↩

2. Stripe’s engineering write-up of Kai, “Meet Stripe’s Knowledge AI Platform” (stripe.dev, 2026). It’s the largest public deployment of the shape this post is about, and the adoption numbers are worth the read on their own: most of Stripe using it within two weeks of launch, and 83% of the company weekly active, including nearly all of GTM. ↩

3. Worth naming, because it cuts against this chapter: what her team built is a set of customer hubs you open inside Notion, and that’s a place you go, which is one of the reasons I said tools die. But they work at Notion and they’re selling Notion, so I’d guess Notion is where most of their workday is already happening. ↩

4. Its members shared a spirit of inquiry and a wish to improve themselves, their community, and the people around them. Mutual improvement was the stated point, and pooling what they knew was the mechanism. ↩

5. Ray and Kim measured this across eighteen years of the BSD forks (FSE 2012): between 10.7 and 15.5% of all patch lines were edits being re-ported between forks, work that occupied 26 to 59% of active developers in a release, and the porting rate does not necessarily decrease over time. That last clause is the whole point. The interest never tapers. Their setting is peer forks rather than a thin fork tracking an upstream, so what I’m borrowing is the shape and not the number. ↩

6. One boundary is better named than hidden: the broker feeds one validated funnel, and nothing subscribes to it. Plays and distillers still pull rows newer than a watermark. A queue at the edges isn’t an event-driven architecture, and I’d rather say so than imply otherwise. ↩

7. UniK-QA (Meta AI, 2022) is the catalog measured: flatten text, tables, lists and knowledge-base triples into one index, search it with a single retriever, and beat the specialized per-source systems by as much as eleven points. Their setting is open questions over Wikipedia and mine is a permissioned corpus of calls and threads, so it’s the shape I’m taking and not the number. Doing the flattening late instead of early is the column-store instinct (Abadi et al., ICDE 2007), and the precise version of my claim is that the index is a derived projection while the typed stores stay canonical. ↩

8. Two honesty notes on the automated version. The hand-tagged corpus was new-business calls only, so the post-sale lane is specified and seeded, not proven against a year of real conversations. And the demo corpus is fictional end to end: the categories are structurally real, and every quote in it’s invented. ↩

9. Azar and colleagues (PNAS 2018) found that the optimal reading frequency rises sublinearly with how fast a source changes. The Slack rule above is the clearest case of this: threads change constantly and I wait two quiet hours anyway, because a thread isn’t a knowledge unit until it stops moving. ↩

10. Junto is built on Sim, self-hosted as the execution engine. Standing on an engine that already worked is most of why the four loops, and not the plumbing, got the build effort. ↩

11. The gateway as the front door, why the 3-second answer to Slack isn’t negotiable, and the rest of the survival mechanics live in What I learned creating a Slack bot. ↩

12. Turpin et al. (NeurIPS 2023) named the mechanism: models produce plausible step-by-step explanations that never mention what actually drove the answer. Anthropic measured a newer version in 2025 and found frontier models mention the hint they actually used in about 25% of the cases where they used it. Both study reasoning traces rather than an agent redrawing its own tool run, so this is evidence for the failure mode and not for my instance of it. ↩

13. Deterministic here means the same trace yields the same bytes. If layout depended on anything outside the trace, the snapshot tests below wouldn’t hold. ↩

14. The count in the caption matters. A filter that hides things without saying how many it hid is just a lie with good manners. ↩

15. 417 is where the count stood the morning the merge froze. The suite has grown since. The two bugs turned up in ordinary live use, not in any clever hunt. ↩