We had everyone at Sanity build an agent. Knowledge Bases are why it didn't turn into utter chaos.
- Even Westvang Co-founder and product person at Sanity
- Rostislav Melkumyan Senior SWE
- Knut Melvær Principal Developer Marketing Manager
Published
Now that anyone can build an agent in an afternoon, the new worry is what happens when everyone in a company does. As one CIO put it to the Wall Street Journal this spring: "Because everybody can do it, we're probably going to end up with a lot of people having the same types of agents."
It’s not wrong.
The expected response to this agent sprawl is to pull out the red tape. Establish a central team that reviews everything and write down policies that, let's face it, few actually read.
There are two ways to go, and both cost you something:
- Lock it down, and the people who know the tedious work best never get to try automating it.
- Let it loose, and you end up with five agents giving five different answers to the same question.
We tried to have it both ways. At our recent all-hands hackathon, we put everyone at Sanity into small teams and gave them about three hours (plus lunch) to "go solve your team's most annoying ask." We now have 80 agents, built by sales, finance, support, engineering and pretty much everyone in between. Some of them overlap in concerns, but that’s OK.
#
It didn't turn into chaos (and not because we wrote a policy). Agents built on our custom agent harness, @s, are cheap to start and even cheaper to kill. Killing one doesn't cost much, because what it knows doesn't live in the agent. It lives in a
For example, the Can I Expense agent looks up finance's travel policy in a Knowledge Base, instead of keeping its own copy in its instructions. If we shut the agent down tomorrow, the policy is still there for the next one. So if you're worried about agent sprawl, we think you're worrying about the wrong thing.
The sprawl of agents isn't really the problem. The sprawl of facts is: policies pasted into prompts, and knowledge that disappears the day someone deletes the agent it lived in.
Keep the facts in Knowledge Bases, and agents become cheap to try and safe to throw away. We will keep the ones that work running, and the ones that don't are a push on the unpublish button away from gone (without taking what they knew with them).
If you want to learn more about how we built the harness, head over to our engineering blog.
#
A lot of work only exists because the information is scattered.
An engineer digs through production logs to work out when a problem started and which customers it hits. A support engineer checks whether other customers report the same thing before deciding if a ticket is an incident. A solutions engineer sets up a demo by hand: a new organization, a Studio, a fork of the code, a website. Someone answers "can I expense this?" by logging into the intranet and reading the travel policy (again).
These are some of the agents that picked up that work:
- Investigates production outages from logs.* Sherlog* tells you whether a service is healthy, when a problem started and which endpoints it hits. On its first day it investigated a real outage, with error counts and a timeline. It was indeed helpful!
- Decides whether a ticket is an incident.* Smokey* weighs severity, checks whether other customers are reporting the same issue, and links to the incident process. On a real ticket it found an investigation already running, so nobody declared it twice.
- Spins up a working customer demo.* Demo Concierge* finds a demo template, provisions a working copy (organization, Studio, fork and website) and returns the links.
- Answers security questions from policy.* DEAL* knows our security and compliance policies, including which documents can be shared under NDA. Its SOC 2 Type 2 answer on the day was correct and ready to send to a customer.
- Ties product goals to customer calls.* Ground Me* connects a product team's OKRs to what customers say on sales calls, with revenue at stake, renewals and who to follow up with. It reads support threads too, so you also find out when something you shipped broke things for a customer.
- Tells engineers how changes land.* Engineer2Field* explains how a change will be received by the field and what customers are asking for.
- Finds a customer to name-drop.* Namedropper* finds existing customers that look like the prospect you're about to talk to ("fintech customers onNext.js
- Translates internal jargon.* Huh?* explains service codenames, Linear team keys and sales acronyms.
- Digs up a feature's history.* Archaeologist* tells you when something shipped, what was tried before, and who to talk to before you start.
- Finds where we contradict ourselves.* World Map* spots where we call the same thing different names across docs, the product UI, APIs and code, and which team to ask about it. Its builder had been thinking about our terminology for three years before getting an afternoon to do something about it.
- Keeps facts with named owners.* Hirð* keeps a fact sheet where every fact has an owner and a last-verified date. A changed fact stays unverified until its owner confirms it.
- Answers "can I expense this?"* Can I Expense* checks a purchase against our expense and travel policy, explains why if it isn't allowed, and helps prepare the ones that are.
A few stats that made us go "wait, what?":
- The agents needed new tools, so people built them on the spot. We went from 9 tools to 105, and most of them were built in a single afternoon.
- On the busiest day, 28 of the 78 changes merged into the codebase were pull requests that @s opened itself.
- The harness behind all of it was built by one engineer in under four weeks.
- Our agents have run more than 1,400 times so far.
#
Making an agent on @s takes minutes. You write instructions, pick tools and publish a document in a Sanity Studio. You can also just ask @s to do it for you. There's no new bot to install and no repo to clone: every agent answers in Slack behind one name, @s, which sends each question to the agent whose description fits best (or asks you to pick).
Teams shipped agents from the Studio without touching code or needing access to GitHub. When an agent needed a tool that didn't exist, developers opened pull requests during the afternoon, and so did @s itself.
#
Easy to start only works if it's just as easy to stop. So the guardrails live where people ship the agents:
- The Studio catches mistakes before they ship. A name the router has reserved, two agents claiming the same channel, a tool that needs a sandbox it doesn't have. Sanity Studio’s custom validation rules made this very easy to set up.
- A person reviews every new tool. And the pull requests @s opens itself can only touch its tools and connectors.
- Agents never see a secret. Only Sanity staff can interact with the agent, even in shared channels, and every model call asks for zero data retention.
- The description is a contract. The router only knows an agent by its description, so an agent that claims too much gets noticed fast. Two of ours both claimed "any question starting with 'who'", and one of them added "prioritize over 'who is'" to its description. We noticed and fixed it rapidly.
Of course, it's unreasonable to expect all the agents that were created in an afternoon to earn their existence. Some overlapped, some were broken, and some were sillier than you'd want running in the company Slack (looking at you, Shamegent). There were fewer of those than we expected, though, and quite a few of the teams that went for fun also built something useful.
Before the hackathon, we decided that agents that find users get maintained, and the rest are killed off without ceremony (which is as easy as unpublishing a document). All agent interaction that happens in public channels is stored for insights, so it’s fairly easy to review who is earning their keep.
#
Most of what teams built worked on day one: 42 of the 61 agents entered at the hackathon worked fully or partly. What held the rest back wasn’t the prompts. Every agent that didn’t work failed on access: a sales-call source it couldn’t reach, a data warehouse table it couldn’t query, a Slack channel the bot wasn’t in, a tool that wasn’t live yet. Most of the partial ones failed the same way.
If you’re putting agents in front of a whole company, sort out access to the systems and the context before you add more authors.
Identifying and locating context was the other hurdle. Pointing a Knowledge Base at a source takes minutes. Figuring out what to point it at took a lot longer. People had to ask which dataset held the staff list, or wait for access to the docs they needed, and one team set up a whole new Sanity project just to give their material somewhere to live. Some of the most common questions don't have a source at all. Several teams wanted an agent that could answer "who here knows about X?", but that answer lives in Slack threads, Linear issues, pull requests and doc comments, not in a document you can point at.
Turns out that hunting down the knowledge is the actual work. It also matters how you describe what a Knowledge Base is for, what purpose it has, because that decides what facts are kept and how they are organized.
One team found theirs had left out authors because the purpose never said authors mattered. Needless to say, this exercise was also very useful product feedback.
#
"Configuring the agent is the easy part," our hackathon brief said. "The hard part is giving it the right context." Getting the context right means agreeing on what's true, writing it down, and deciding who keeps it that way. That's what the day was really about: each team turned its own material into something an agent could look up and trust, using Knowledge Bases in Sanity Context.
Most of what got built was about getting knowledge out of people's heads (the stuff you'd normally have to ask someone about) and into a place an agent can find it.
Ten of the twelve agents above look up their facts in a Knowledge Base. So do 56 of the 80 agents on @s, spread across 62 Knowledge Bases that teams built from their own material. Three things made them work as shared infrastructure rather than as a feature of each agent:
- Teams own their facts. Every team was asked to build its own Knowledge Base from its own material, and to write down what's in it, where it came from and who keeps it correct.Can I Expense reads finance's policies.DEAL reads security's.
- They're also shared. 26 of the 62 Knowledge Bases feed more than one agent, and the two most-used ones feed seven agents each. A fact fixed once is fixed for every agent that reads it.
- Gaps are said out loud. When an agent can't reach its Knowledge Base, @s tells it to say so rather than answer from memory. An agent that admits it doesn't know is more useful than one that is confidently wrong.
Our CEO Magnus Hillestad recently wrote that agents draw on five layers of context, and that the one most teams underestimate is canon. Namely, what a company has decided and stands behind. He also predicts that building it will show you that your company "disagrees with itself."
And for us it did. The World Map agent found that one of our product concepts goes by about ten different names across docs, the product UI and APIs, each with its sources.
The other layers mapped onto @s like this:
- Records come in through tools: production logs forSherlog , support tickets forSmokey , sales-call data forGround Me .
- Process sits inskills and in the tools themselves.Hirð won't mark a changed fact as verified until its owner confirms it, however the question is phrased.
- Situation is the Slack thread: the recent messages, who's asking, the channel and their local time.
- Memory is the layer we haven't built yet. An agent doesn't carry lessons from one conversation into the next. We do keep a record: exchanges in public channels go to Context Insights, so we can see what people asked and where answers fell short. What we are testing out is a scheduled agent that reads that record each week and proposes fixes to an agent's instructions or Knowledge Base, for the person who owns it to approve. That's Magnus's point about memory: it only becomes canon once someone has reviewed it.
#
We're a company that asks you to keep your content in one place, so it's fair to ask why we wouldn't tie our agents to one as well. The difference is what each part is for. Your facts need one home, with owners, so every agent reads the same truth. The agent on top probably will change often, so it should be the cheapest thing to replace.
That's how @s is built. Each agent picks its own model, and we swapped the model behind the router two weeks into the project. The harness is a thin layer we own. And Knowledge Bases reach agents through MCP, so the same facts can serve @s today and whatever a team builds next, whether that's on eve, Mastra, the Vercel AI SDK or something that doesn't exist yet.
#
We tell customers to build their own agents on Sanity instead of buying off-the-shelf ones. Before this hackathon, most of us had never done it ourselves (a bit awkward, we know). Now most of us have, and the advice we'd give is to start with the context. The agent takes minutes. Gathering what's true about your business and compiling it into Knowledge Bases is what grounds the agents and keeps them on track.
For now, our agents will only act when asked to. But in the future, we might engineer them to be more proactive. Then it will be important to apply Magnus' rule: "The more autonomy you give an agent, the more of its context needs to be canon."
#
If you want to try this with one team's own material, these are the places to start.
- **New to Sanity?**[Start a new project](https://www.sanity.io/get-started?ref=context) with Sanity Context switched on.
- Already on Sanity? Knowledge Bases are in beta. An organization admin enables them on theLabs page in Manage.
- Build one.Create a Knowledge Base walks through adding sources and reviewing the result, andKnowledge Base source types lists what you can feed it: datasets, websites and files like PDFs.
- Fix what it finds. When your sources disagree,Resolve Knowledge Base issues covers what to do about it, andKeep a Knowledge Base current covers the upkeep.
- Connect an agent. Knowledge Bases reach agents through Context MCP. Start withConfigure an MCP , then follow the guide for your framework:Vercel AI SDK ,OpenAI Agents SDK orLangChain .Patterns and best practices covers what holds up in production.
- Take the course.Ship an agent or agentic workflow on Sanity on Sanity Learn walks through building an agent on your content, including where a person belongs in the loop.
- See it in practice.How Braze built a competitive intelligence tool in one day (video).
- Read the thinking behind it. Magnus'sThe five layers of agentic context , andEverything we shipped so you can trust agents with your content .