Does a 50-person company need an intelligence stack?

It needs the thinking behind one, not a platform. A company of 20 to 200 people usually already has the raw material — documents, a CRM, support tickets, a few AI subscriptions. What is missing is the connective tissue: one searchable knowledge layer, a deliberate choice of models, a register of what runs by itself, and a named owner for each part. That can be built in small steps with open-source parts and the tools you already pay for.

Which layer of the intelligence stack should we build first?

Usually knowledge, because every other layer depends on it. An agent that cannot find the right answer in your own information will guess, and no model upgrade fixes that. The exception is guardrails: if you already have anything running unattended, put spend caps and a kill switch on it before you build anything new.

Who should own the intelligence stack in a small company?

One senior person, with the authority to make decisions across teams. In a company without a CTO or Chief AI Officer that is often a fractional or embedded leader — a Forward Deployed CTO when the work is mostly product and platform, a fractional CAIO when it is mostly operations and business-wide adoption. What matters is that one person owns the whole stack, not five people owning one layer each.

All of Pulse

Building an intelligence stack inside a 20–200 person company

Q: What is an intelligence stack?

An intelligence stack is the set of layers a company needs to run AI as part of how it works, rather than as a handful of separate tools. We describe it as five layers: knowledge (your own information, made searchable), models (which AI models you use and how requests are routed between them), agents (the software that uses models to do real work), guardrails and evals (the limits and tests that keep that work safe and correct), and people and decision rights (who owns each piece and what humans still decide).

ExponenLabs22 September 20268 min read

Most companies between 20 and 200 people already use AI. Someone has a chat subscription. Sales has an email writer. Support is trialling a bot. Engineering has coding agents. None of it talks to anything else, and nobody can say what it all costs or what it is allowed to touch.

That is not an intelligence stack. It is a collection of subscriptions.

An intelligence stack is what you get when those pieces sit on shared foundations: one place your knowledge lives, a deliberate choice of models, agents that are built rather than bought one at a time, limits on what they can spend and do, and people who own each part. We think about it as five layers. None of them needs a platform team. All of them need an owner.

Layer 1: Knowledge

Every useful AI system in a company answers from that company's own information. Contracts, product specs, past tickets, pricing rules, the way you handle a refund. If a model cannot find the right fact, it will produce a plausible one. That is not a model problem. It is a knowledge problem.

The knowledge layer is the part that makes your information findable by software. In practice that is retrieval-augmented generation (RAG): search your data first, then give the model what was found. The detail that matters for a business is that search has to work two ways at once. It has to understand meaning, so "how do I cancel" finds the page titled "ending your subscription". And it has to respect exact terms, so a part number or a customer ID returns that record and not something similar.

We published a working example of this, Hybrid Search RAG, which runs both searches over your own database and merges the results. It uses a recipe recommender to stay easy to follow, but the pattern is the one we build into real products.

What to do first: pick one body of knowledge that people ask about every day — support answers, internal policies, product documentation — and make that searchable well. One source done properly beats ten sources done badly.

Layer 2: Models

The model layer is the choice of which AI models you use, and how each request reaches the right one. Most small companies never make this choice. They use whichever model came with the first tool they bought.

That works until it does not. Two things change the picture. First, different jobs need different models: a classifier that sorts emails does not need the same model as an assistant drafting a contract summary, and paying frontier prices for simple work adds up. Second, some data should not leave your control at all, which means some requests may need a model you host or one with contract terms you have actually read.

The practical answer is routing. Put a thin gateway between your applications and the model providers, so you can send each kind of request to the model that fits it, switch providers without rewriting code, and see cost per use in one place. Open-source gateways do this well. We wrote a fuller guide to the open- versus closed-source choice in Open-source or closed-source AI tools?

What to do first: list every place a model is called today, what data goes into it, and who pays for it. The list is usually longer than people expect.

Layer 3: Agents

Agents are software that use a model to do a task with some autonomy: triage a ticket, draft a reply, reconcile an invoice, update a record. This is the layer everyone wants to start with, and the one that goes wrong most often when the layers below it are missing.

An agent is three things, and each can break separately. The harness is what it can touch: tools, files, memory, permissions. The loop is how it decides it is finished. The graph is the fixed route through a process, where you already know the steps. We explained all three in plain English in Harness, loop and graph.

The other half of this layer is improvement. An agent that works in a demo will meet inputs in production that nobody tested. You need a way to see how it actually behaves and change it on evidence rather than instinct. Our open-source Recursive Agentic Improvements scaffolds an agent, tests it against repeatable scenarios, and improves it step by step. It works across the main agent frameworks.

What to do first: one agent, on one workflow, where a mistake is cheap and easy to spot. Build it, watch it, fix it, then decide on the second.

Layer 4: Guardrails and evals

This is the layer that decides whether AI saves you money or quietly spends it. Guardrails are the limits on what an agent can do and spend. Evals are the tests that tell you whether its output is still correct after you change a prompt, a model or a data source.

Three guardrails matter most in a company this size:

Spend caps per run and per hour, not just per month. A monthly budget only trips after the money is gone. We wrote about how to set sensible numbers in What a sane agent spend cap looks like.
A kill switch one person can use in under a minute, without a deploy.
An agent register. A single list of every agent and automation that runs by itself: what it does, what it can access, what it may spend, and the named person who owns it. It is the most boring document in the stack and the one we check first.

Evals do not need to be elaborate. A few dozen real examples with known good answers, run every time something changes, will catch most regressions before a customer does.

What to do first: write the agent register. If you cannot list what runs by itself, nothing else in this layer can be trusted.

Layer 5: People and decision rights

The last layer is not software. It is who decides what.

Every AI workflow has points where a person must still decide: approving a refund above a limit, sending a contract, changing a price, telling a customer something new. If those points are not written down, one of two things happens. People avoid the AI because they do not know what they are allowed to let it do, or they let it do too much because nobody said not to. Both are expensive.

Decision rights answer three questions for each workflow: what the AI does alone, what it drafts for a person to approve, and what stays entirely human. Our free AI-Native Business Deployment planner turns six plain answers about your business into exactly that split, with a week-one plan.

This layer also covers training. The people whose work changes need to understand what the AI does and where it fails, or they will either ignore it or trust it blindly.

Who builds it, and in what order

The order we usually follow is knowledge, then guardrails on anything already running, then models, then the first agent, then decision rights written down as the agent goes live. It is not strict. It is ordered so each layer makes the next one safer.

The harder question is ownership. In most companies of this size, each layer ends up with a different person, or with nobody. IT owns the subscriptions, a team lead owns one agent, finance notices the bill. Nobody owns the stack.

That is the job of one senior person. When the work is mostly product and platform, that person is a CTO. When it is mostly operations — AI across sales, support, finance and people — it is a Chief AI Officer. Most companies of 20 to 200 people do not need either full time, and cannot hire one quickly. That is why we built the Forward Deployed CTO and Fractional CAIO roles: one senior person inside your team who builds the stack with your people and hands it over.

Frequently asked questions

What is an intelligence stack? The layers a company needs to run AI as part of how it works: knowledge, models, agents, guardrails and evals, and people and decision rights.

Does a 50-person company need one? It needs the thinking, not a platform. Most of the raw material is already there. What is missing is shared foundations and an owner for each part.

Which layer should we build first? Usually knowledge, because every other layer depends on it. If anything already runs unattended, put spend caps and a kill switch on it first.

Who should own it? One senior person with authority across teams. In a smaller company that is often a fractional or embedded CTO or Chief AI Officer.

Working with us

You can build all five layers yourself with the open-source parts linked above, and we would rather you did that than bought a platform you do not need. If you want someone senior inside the team to lead it, see how a Forward Deployed CTO works, or, if the change is across the whole business rather than the product, the Fractional CAIO.