Product · The Brain
Agents fail without context. Yours won’t.
The Brain is your company’s central context hub — business knowledge, data definitions, and policies as code, fully visible and fully yours. Every agent you run reads the same brain.
No black box between your data and your agents
Connect your sources. In the middle sits a set of files you can open, not a model you have to trust. Your coding agent builds it and keeps it current with the Lynk build plugin; every file type is explained in the docs (opens in a new tab).
One brain for every person, agent, and use case
Business teams ask in the UI. Data teams edit in their IDE. Agents retrieve over MCP and APIs — support bots, ops automations, your own builds. One context hub, no copies drifting apart.
Which campaigns ran over their cost-per-activated-user target this week?
Two: spring-sale-search (38% over) and q3-retargeting (31% over). Want the week-by-week breakdown?
context used: campaign package · glossary: activated user
Anyone can ask; answers are built from the brain, and the data team can open every conversation down to the SQL. Meet the data agents →
brain/
├── entities/
│ └── campaign/
│ ├── knowledge.md
│ └── schema.yml
├── glossary.md
├── policies.md
└── skills/
└── churn-investigation/SKILL.mdOpen it in Cursor or Claude Code, edit like any code, ship through your PR flow — validations and evals run before anything goes live.
The right context at the right time.
No more guessing.
Agents stop hallucinating definitions and re-deriving your business on every question. They carry less context, spend fewer tokens, and return accurate results — because meaning, data, and rules come from one governed place.
Plugs into all your apps and docs
The brain is assembled from what you already have: warehouse schemas, dbt models, BI definitions, docs, tickets, and chats. Nothing gets re-authored from scratch — existing knowledge is read, structured, and written down as files.
The tribal knowledge living in Slack threads and Google Docs lands in the same brain as your metrics, where every agent can read it.
maya why is CPAU up?? are we counting
trial signups as activations?
tom no — activation = created a workspace
and invited 3+ teammates.
it’s in the Q2 planning doc## activated user
A user who created a workspace and invited
three or more teammates. Trial signups are
never counted as activations.
used by: cost_per_activated_userBuilt by your favorite agent, straight into your Git repo
Your coding agent (Claude Code, Cursor, whichever you run) assembles the brain from those sources with the Lynk build plugin, and lands every file as a pull request in your repo.
What lands is plain markdown and YAML: the campaign entity package, and the spend policy that governs it. Readable by humans, readable by agents, portable anywhere — no vendor lock-in.
See the build flow# Campaign
A campaign is one paid-acquisition push on a
single channel — one budget, one audience, one
start date. Multi-channel launches are grouped
by `initiative`, never merged into one campaign.
## How campaigns are judged
Performance is judged on cost per activated
user, not cost per signup. Signups are cheap;
activation is the first moment of real value
(see glossary: activated user).entity: campaign
grain: one row per campaign
sources:
campaigns: analytics.campaigns
spend: analytics.campaign_spend
activations: analytics.activations
features:
status: draft | live | paused | completed
cpau_target: cost-per-activated-user target
metrics:
spend: sum(spend_usd), total channel cost
activated_users: count(distinct user_id)
cost_per_activated_user: spend / activated_users
relationships:
initiative: campaign belongs to one initiative
users: campaign has many users, via attribution# Spend authority
An agent may pause a live campaign on its own
when the campaign runs 30% or more over its
cost-per-activated-user target for the week.
Budget increases are never autonomous: the
agent drafts the change, a campaign owner
approves it.
Every autonomous action is logged, with the
compiled query behind it.Agents load only what the task needs — and never write SQL
Over MCP, an agent first lists what exists in the brain, then loads only the files its task needs — the campaign package for a campaign question, the refund policy for a support ticket, nothing else. The brain grows; the context an agent carries stays small, and so does your token bill.
For data, the agent picks your named terms, and a deterministic engine compiles the same SQL from the same request — every time, on your warehouse, under access control.
entity: campaign
metric: cost_per_activated_user
window: this_week
compare: cpau_target * 1.30
filter: status = livewith spend as ( select campaign_id, sum(spend_usd) as spend from analytics.campaign_spend where spend_date >= date_trunc('week', current_date) group by campaign_id),activated as ( select campaign_id, count(distinct user_id) as activated_users from analytics.activations where activated_at >= date_trunc('week', current_date) group by campaign_id)select c.campaign_id, s.spend / nullif(a.activated_users, 0) as cost_per_activated_userfrom analytics.campaigns cjoin spend s on s.campaign_id = c.campaign_idleft join activated a on a.campaign_id = c.campaign_idwhere c.status = 'live' and s.spend > 0 and s.spend >= c.cpau_target * 1.30 * coalesce(a.activated_users, 0)Stays healthy and current as things change and break
Businesses drift: schemas change, definitions evolve, someone renames a column on a Friday. Schema validations reject conflicting definitions, and evaluations replay your agents’ real tasks against every proposed change: test questions with expected answers, scored by semantic similarity. A break is caught in review, not in production.
Between changes, the build agent watches your sources for drift and opens PRs to keep the brain current.
How brain health worksschema validations ✓ no conflicting definitions
evals ✓ 41/41 real tasks passing
freshness campaign package updated 2d ago
drift watch analytics.campaigns:
column `channel_group` added
→ PR #219 opened by the build agentManaged as code, shipped like code
The brain is a directory in your repository, so your existing engineering discipline applies unchanged: branch it, review it, run validations and evals in CI, merge it. Your PR flow is the approval flow — no new tool to govern.
Every definition an agent uses has an author, a reviewer, and a history. When someone asks why a number is what it is, the answer is a commit.
$ git checkout -b tighten-spend-policy
edited: policies.md
$ git push
PR #214 “tighten campaign spend policy”
ci / schema validations ✓
ci / evals ✓ 41/41
merged → live for every agentFAQ
Everything your team will ask
What exactly is the Brain?
Your company’s context graph: business knowledge, data definitions (entities, features, metrics, relationships), and policies, written as markdown and YAML in your own Git repository. Agents read it before touching your data, and a deterministic engine compiles their requests into SQL on your warehouse — so what they know and what they compute both come from files you own and review.
How is it different from a data catalog or a semantic layer?
A catalog tells you which tables exist and who owns them — useful input for context, but not something an agent can execute. A classic semantic layer governs metrics for dashboards, but carries no business knowledge, no policies, and nothing an agent can discover and call.
The Brain holds meaning, data definitions, and rules in one place: files agents can read, plus named terms that compile to deterministic SQL.
How much work is it to set up?
Less than you’d expect, because you don’t write the files — your coding agent assembles the first brain from your warehouse, dbt, and docs, and you review pull requests instead. Design partners typically ask their first questions within minutes and are onboarded in a day or two, with our team handling the heavy lifting.
How do I know a change won’t break my agents?
Two gates run before anything reaches production. A schema validation refuses a second definition of any metric or entity, so conflicts can’t land. And every proposed change is tested against the questions your agents actually get, scored by semantic similarity — tests, but for meaning. Breaks surface in review, while they’re still cheap to fix.
Can the agents we already run use it?
Yes. MCP and APIs expose the Brain to Lynk’s own data agents, the agents you build, and the assistants your teams already use. Each one retrieves only the files its task needs, with access control enforced in the query path itself: per-domain scoping decides which entities and data an agent can reach, so an agent scoped to marketing can’t read finance data, no matter what it’s asked.
What if the brain doesn’t have an answer yet?
The agent says so instead of improvising. Agents choose among your named definitions; when a request doesn’t map to one, the agent asks a clarifying question or states the gap rather than inventing an answer. The gap then becomes a work item: the conversation log shows what was asked for, and once the missing definition lands through your review, every agent has it.
Where does my data live?
The brain lives in your Git repository, and your data stays in your warehouse: Lynk connects with read-only access and runs the compiled SQL there. What an agent sees is the context it retrieved and the query results it asked for — never a copy of your warehouse.
What about vendor lock-in?
Your context is never locked in. The Brain is plain markdown and YAML in your Git repository — version-controlled, portable, yours forever. If you walk away, everything you taught it goes with you.
Build your company’s brain now
Connect your sources, let your coding agent assemble the brain, and get first answers in minutes. Your context lives in your repo — and stays yours.