Most internal AI agents are switched off within a quarter, and the reason is almost never the model. It is scope. Here is the architecture we build instead, the twelve-week sequence that gets it into production, and how the same system extends from HR operations to project management.
Key Takeaways
- Most internal agents fail because of scope, not the model.
- Every focused area needs scoped facts, documents, actions, and forty golden questions.
- Computed answers run as deterministic queries; policy answers cite a human-edited vault.
- A shared substrate makes each new focused area faster and cheaper to build.
- Refusals and human approval gates are what make the agent trustworthy.
Introduction
A pattern shows up again and again in enterprise AI projects. A team connects an assistant to the company wiki, the HRIS, the ticketing system and a shared drive, demos it to leadership, gets applause, rolls it out, and watches usage collapse over the following eight weeks. The post-mortem usually blames the model, the retrieval quality or the data hygiene.
The real cause is upstream of all three. The agent was given a domain so wide that nobody could define what a correct answer looked like, so nobody could test it, so nobody could trust it. When a system cannot be tested, its first confident wrong answer is fatal, because there is no evidence to weigh against the anecdote.
The fix is not a better model. It is a smaller box.
Almost every enterprise wants the same thing and calls it roughly the same name. A company brain: one system that understands how the business runs, answers questions about it, and can take action inside it. The ambition is correct. The mistake is building it as one thing. A company brain that survives contact with real users is a portfolio of narrow, testable focused areas sitting on a substrate you build once. This article covers both halves, the architecture and the twelve-week sequence that gets the first area into production.
What a focused area actually is
A focused area is one bounded operational domain, defined as an engineering object rather than a theme. It has four walls, and all four are required. Drop any one and the system degrades into the assistant that gets switched off.
Four walls, all required. The fourth is the one teams skip, and skipping it is why the first wrong answer becomes fatal.
The fourth wall is the test of whether you have a real project. If you cannot write down the forty questions the agent must get right, you do not have a focused area, you have a demo. Those forty questions get written before any code, and roughly a quarter of them should be deliberately unanswerable, where the correct output is a refusal and a handoff to a named human.
Two kinds of questions need two kinds of retrieval
Inside any operational domain, questions fall into two categories that almost nothing in the market handles well at the same time.
The first category is computed. How many requisitions has engineering had open for more than sixty days. How much leave has this employee accrued as of the end of the quarter. What is the median time from offer to acceptance this year. These answers are arithmetic over joined records, and a language model performing that arithmetic inside its own context is a liability, not a feature.
The second category is judged. What is our policy on converting a contractor. Which interview loop applies to a senior backend role. When does a role need a compensation review. These answers live in prose, they carry nuance, and the only acceptable output cites the document it came from.
Two tools map cleanly onto these two categories, and the interesting architecture runs both under a single router.
PromptQL for the computed half
PromptQL is Hasura’s data agent. Its architectural claim is the one that matters here: the language model is used to generate a multi-step query plan in a domain-specific language, and that plan then runs deterministically as code outside the model, covering retrieval, computation and semantic steps. Hasura has been candid that the marketing phrase “100 percent accurate” does not literally hold; the defensible claim is repeatability, because the computation happens in Python and SQL rather than inside the model’s head.
That distinction is exactly what regulated and operational domains need. Two people asking the same question about headcount on the same day get the same number, and you can inspect the plan that produced it.
Be clear-eyed about the cost of entry. PromptQL is a data project, not a plug-in. It requires connectors, HML metadata and the DDN CLI, and it assumes you have someone who can model your entities and relationships properly. Its public footprint is also still thin, which makes it an early-adopter choice rather than a safe default. If you already run a mature semantic layer over a warehouse, that layer can play the same role.
Obsidian and MCP for the judged half
Obsidian sits at the opposite end of the spectrum. A vault is a folder of Markdown files with wikilinks forming a real graph and git providing history. Every major language model was trained on Markdown, so an agent reads a vault natively with no parsing layer, no format conversion and no ingestion pipeline to keep warm.
The Model Context Protocol ecosystem around Obsidian is now mature enough to pick a posture rather than take what you are given. Some implementations run as native Obsidian plugins and get access to the internal knowledge graph, Dataview queries and backlink analysis. Others read the vault files directly with no plugin required and no running Obsidian app, which is the right choice for a server-side deployment.
The strategic advantage is not technical. It is that your HR generalist or delivery lead can edit the policy corpus directly, in a text editor, and the change goes through a pull request with a reviewer. The people who own the policy own the source of truth, and engineering is not a bottleneck on a leave policy update.
Computed questions go left and get calculated. Judged questions go right and get cited. Questions needing both get one leg each, and the composer refuses if either leg comes back empty.
That refusal behaviour is the product. A question like “am I eligible for the sabbatical, and how long until I am” needs both legs: a policy note defining eligibility and a computed tenure figure. If the vault has no sabbatical note, the correct output is not a plausible paragraph. It is a refusal that names the person who can answer.
The use case: hiring operations at a 600-person company
The scenario below is a composite drawn from how these builds actually sequence, not a single client case study. The figures are arithmetic from the stated assumptions rather than measured outcomes. We do not publish invented benchmarks.
A 600-person healthcare SaaS company. HR team of six. Two of them spend most of their week answering the same questions: leave accrual, the parental policy, whether a contractor conversion needs a new requisition, what the interview loop is for a senior backend role.
Week one: sort before you build
They build nothing. They export four months of HR ticket subjects and sort them. Out of roughly 900 tickets, about 61 percent cluster into two topics: leave and hiring process. The rest is a long tail of genuinely individual situations that should never go near an agent.
That sort is the entire strategy. They pick one focused area, hiring operations, and deliberately leave leave-and-benefits for later even though it is the larger cluster, because hiring has a lower blast radius if the agent is wrong.
Weeks two to four: write the judgment down
Someone rewrites the hiring playbook as 34 Markdown notes in an Obsidian vault. One note per decision point. Each carries a last_reviewed date in the frontmatter and wikilinks to related notes. The recruiting coordinator does most of this, not an engineer, because it is writing work.
In parallel, an engineer models four ATS and HRIS tables through PromptQL so requisition age, stage conversion and offer cycle time are computed rather than guessed.
Week five: the evaluation set finds the real bugs
They write the forty golden questions before the agent exists. Twelve are deliberately unanswerable. The first build passes 22 of 40.
The failures are the valuable part. It answers six of the twelve unanswerables with confident fiction, which is a prompt and gating problem. And it gets requisition age wrong, because two systems disagree about what “opened” means. That second failure is a data definition problem that predates AI entirely, and fixing it improves every dashboard in the company.
Week eight: a small room, with receipts
It goes live for eleven people in one Slack channel, not the whole company. Every answer carries a link to the vault note it came from. Click-through to source turns out to be the highest-value feature in the product, because it converts “the bot said so” into “the policy says so,” and those are completely different conversations.
Week ten: one write action, with a gate
Exactly one write action goes live: open a requisition from an approved template. The agent drafts, shows the diff, and a human approves.
Rejections are logged with a reason, the same as approvals. Both branches write to one audit record, which is what turns “we used AI” into something a compliance officer can sign.
In the first fortnight it drafts 19 requisitions and a human rejects three: two with the wrong hiring manager, one where the role had changed since the template was written. Those three rejections are worth more in the board conversation than the sixteen that went through, because they are the evidence that the gate works.
Week twelve: what actually changed
The two HR business partners get back a meaningful share of the roughly 550 hiring-related tickets they field annually, but not all of it, because the agent handles the repeatable majority and escalates the rest. That is the expected benefit and it is real.
The unexpected benefit is larger. The vault became the company’s actual policy of record. When someone found that the parental leave note contradicted the handbook, the fix was a pull request with a named reviewer rather than an email thread that ended in ambiguity. The agent did not only answer questions about policy. It forced the policy to become unambiguous enough to be answerable.
The same architecture for project management
When leadership asks for the second focused area, it takes roughly a third of the calendar time, because the router, the approval gate, the audit log and the evaluation harness already exist. Project management is usually the strongest candidate, and often an easier build than HR.
Three reasons. The facts are already structured in Jira, Linear or Azure DevOps, so the modelling work is shorter. The recurring artifact is obvious, because someone is already writing a weekly status report by hand. And the blast radius of a wrong answer is a corrected document, not a compliance event.
How the four walls map
- Scoped facts. Issue transitions, sprint scope changes, pull request cycle time, CI pass rate, time entries, and allocation by person. Computed, not retrieved.
- Scoped documents. The delivery playbook as a vault: definition of done, the escalation ladder, estimation norms, client communication templates, and the decisions that came out of the last twelve retrospectives.
- Scoped actions. Draft the weekly client status update. Propose a risk register entry. Flag tickets that have gone stale against the playbook’s own threshold. All drafted, all approved by a human.
- Scoped evaluation. Forty questions including “which tickets are blocked and on whom,” “is this sprint’s committed scope larger than the trailing three-sprint average,” and unanswerables such as “will we hit the deadline,” where the only acceptable output is a forecast with its assumptions stated, or a refusal.
The status report is the wedge
A delivery lead running six client accounts writes six status updates a week. Assume 45 minutes each with the gathering, the cross-checking and the diplomacy. That is four and a half hours, every week, of work that is mostly transcription from systems that already hold the answer.
The agent drafts each one from computed facts plus the playbook’s tone and structure. The lead edits and sends. The constraint that makes this trustworthy rather than dangerous is that the agent cannot assert progress that no ticket transition, commit or approved deliverable supports. It will write “no movement on the integration workstream since the 9th” if that is what the data says, even when the lead would have phrased it more gently. Softening is the human’s job, and the human should have to do it deliberately.
The risk register is where it earns its keep
Pattern detection over delivery data is genuinely hard for humans to do consistently across six accounts, and genuinely easy for a system with a query plan. A ticket reopened three or more times. A pull request open longer than seven days. Scope added after sprint start without a corresponding date change. Two people allocated above capacity in the same fortnight.
The agent proposes a risk entry with the evidence attached. It does not decide that something is a risk, it does not assign a severity, and it does not tell the client. A person does all three, and the proposal plus the decision both land in the audit record. Six months later, that record is the most honest retrospective input the organisation has.
Where two focused areas start to compound
Once HR operations and delivery operations both exist, a third area becomes cheap and was previously impossible. Capacity planning needs leave and start dates from the HR facts layer and allocation from the delivery facts layer, plus the staffing policy from a vault. The router already knows how to fan out to two fact sources and recombine. That is the compounding return, and it only arrives if the first area was scoped small enough to actually finish.
Where else the pattern lands
| Workflow | Computed facts | Written judgment | First write action |
|---|---|---|---|
| Finance operations | Invoice ageing, budget against actual, collections status from the ERP | Approval thresholds, revenue recognition policy, dunning escalation rules | Draft the collections email for a named account |
| Customer support operations | Ticket volume by type, first-response and resolution times, reopen rate | Escalation playbook, severity definitions, named-account handling notes | Propose a priority change with the evidence attached |
| Sales operations | Pipeline by stage, stage ageing, conversion rates, quota attainment | Qualification framework, discounting policy, deal review criteria | Draft the deal review summary ahead of the forecast call |
| IT and procurement | Access requests, licence utilisation, renewal dates, spend by vendor | Access control policy, vendor risk tiers, approval matrix | Draft the renewal recommendation with utilisation evidence |
The shape is identical every time. Somewhere in the business there is a system of record holding facts, a body of judgment that mostly lives in senior people’s heads, and a recurring artifact somebody produces by hand on a schedule. Those three together define a focused area.
The company brain is a portfolio, not one agent
This is the structural claim the rest of the build rests on. Teams that set out to build “the brain” produce one enormous agent, and it fails for the reasons in the opening paragraph. Teams that build a substrate and then add focused areas onto it succeed, and the economics only work because of what gets shared.
Roughly 60 percent of area one is substrate that area two inherits at no cost. That ratio is the business case, and it is why pricing a single agent build as a standalone project misprices it in both directions.
The consequence for planning is specific. Do not evaluate area one on its own return, because it is carrying the cost of a platform. Do not evaluate area two on its own cost either, because it is free-riding on that platform. Evaluate the first three together, which is also the horizon over which the executive sponsor will actually judge the programme.
How to pick your first one
- Volume. Does this domain generate more than fifteen repeat questions a week? Below that, the payback period is too long to survive a budget review.
- Ground truth. Can you name the system of record for the facts, and does it have one definition per field? If two systems disagree, that disagreement is your first deliverable.
- Written judgment. Does the policy exist in writing? If it does not, writing it is the project, and it is still worth doing. Budget for it honestly rather than discovering it in week three.
- Blast radius. What is the worst realistic outcome of a confident wrong answer? If it is an employment, credit or clinical decision, pick a different area first and come back with a track record.
- A recurring artifact. Is there a document someone produces weekly by hand? That is your wedge, your demo and your adoption mechanism in one.
Six decisions before any code
Get these wrong and you rebuild in month four. None of them are AI decisions, which is the point.
Where the conversation happens
Slack or Teams, in almost every case. A standalone web application adds a login that people will not adopt for a tool they use four times a week. This decision also settles your identity source, which the router needs.
Not the agent. Either the semantic layer over your data, or separate vaults per audience, or both. Write this down explicitly, because the default that teams drift toward is “the system prompt,” and that will not survive an audit.
How facts get computed
PromptQL, an existing semantic layer, or a set of parameterized queries exposed behind an MCP tool. The last option is underrated for area one. Ten hand-written queries covering your forty golden questions is a legitimate starting point and buys back three weeks you can spend on evaluation instead.
Where judgment lives
A git-backed Markdown vault is the default recommendation. The test is simple: can the policy owner edit it without filing a ticket? If the answer is no, pick something else, because a corpus that only engineering can change will be stale within two quarters.
What the agent may change
Write the list. One or two actions. If the list has more than three items, you are not building a focused area, you are building a platform, and you should say so on the plan.
What happens on a refusal
A named human, a named channel, and a logged event. “I am not sure” with no escalation path is how adoption dies quietly, because the user learns that asking the agent costs them time rather than saving it.
The twelve-week build sequence
Weeks one to four: two tracks in parallel
The engineering track builds the substrate. An MCP gateway holding connector credentials, the router, which in practice means classifying intent into one of N areas plus an explicit “none of these” bucket, the policy gate, and the audit log schema. The audit log goes in first, not last. Retrofitting it means re-instrumenting everything you have already built.
The business track writes the vault. This is the track that slips, and it slips because nobody was told it was their job. Assign a named owner from the domain, not from engineering. Thirty to forty notes, one per decision point, frontmatter carrying owner and last_reviewed, wikilinks between related notes. Put the hours on the plan where the sponsor can see them.
Week five: write the evaluation set before the agent exists
Forty questions pulled from real ticket history, not from imagination. A quarter of them unanswerable by design. Each one carries an expected answer and an expected source. This document is the contract between engineering and the business, and it is what you hand a skeptical stakeholder when they ask how you know the thing works.
Weeks five to eight: build to the evaluation set
Expect to pass roughly half on the first run. The failures sort into three buckets. Prompt and gating problems, which are fast to fix. Retrieval problems, which usually mean the vault note does not exist or is ambiguous. And data definition problems, where two systems disagree about what a field means. That third bucket is the most valuable output of the entire phase and is worth fixing whether or not the agent ships.
Weeks eight to ten: pilot read-only, with under fifteen people
One channel. No write actions. Every answer carries its source link. Log every question the router sends to the “none of these” bucket, because that list is your area two backlog, written by your users rather than by a strategy offsite.
Weeks ten to twelve: add exactly one write action
Behind the draft, preview and approve gate described earlier. Log rejections with their reasons alongside approvals, because the rejection record is the evidence that the gate is doing work.
Week thirteen onward: area two
Same shape, roughly a third of the calendar, because the substrate already exists and the organisation has now learned how to write a vault.
The team this actually takes
- One backend or data engineer, full time.
- Half a platform engineer for the gateway, secrets and deployment.
- One domain owner from the business at roughly 30 percent for the full twelve weeks. This is the role that projects under-resource most often, and its absence is the single best predictor of failure.
- A security or compliance reviewer at two checkpoints, week zero and week nine.
- A technical lead who owns the evaluation set and its pass rate.
Five people, only one of them full time. The shape of this project tends to surprise organisations that expected to need an AI team.
How you know area one is done
Not “it works.” Four tests, all of them observable:
- It passes 36 or more of the 40 golden questions, with the twelve unanswerables refusing correctly rather than passing by luck.
- The domain owner has edited the vault at least twice with no engineering involvement.
- The audit log can reconstruct any answer from the past thirty days, including which sources it used.
- Someone outside the pilot group has asked to be added.
The fourth is the only adoption signal worth trusting, because it is the only one that cannot be produced by a mandate.
What will bite you
Employment decisions are a regulatory boundary, not a grey area. The moment an agent screens, ranks or scores candidates or employees, you are in EEOC territory, state AI hiring audit obligations, and potentially EU AI Act high-risk classification. Keep the agent on information and operations. Write that boundary into the system prompt, enforce it in the action list, and test it in the evaluation set so it is provable rather than intended.
Permissions do not come free from either tool. Obsidian has no concept of row-level access, so scoping means separate vaults or subdirectories, not clever prompting. PromptQL respects whatever your data layer enforces, which means the semantic layer has to carry the authorization model. The agent is not the right place to implement access control, and any design that puts it there will fail an audit.
Retention and legal hold apply to the transcript. Every conversation is a record. Decide where it lives and for how long before launch, not after the first discovery request.
Staleness is the failure mode nobody plans for. A vault note last reviewed eleven months ago, cited confidently with a link, is worse than no answer, because the citation lends it authority. A last_reviewed field plus a monthly staleness report is a small amount of work that prevents an entire category of embarrassment.
The name itself is a risk. “Company brain” is a useful frame for a board conversation and a dangerous one for a project plan, because scope expands to match the ambition in the label. Use it externally if it helps people understand where you are going. Internally, keep calling them focused areas, keep the action lists short, and make anyone proposing an expansion name the forty questions that come with it.
What this means for how you buy the work
If a partner quotes you four weeks for an internal agent with a write action, they are not counting evaluation. Six weeks is the honest engineering estimate for a scoped read path plus one approved write. The realistic calendar to a trusted internal launch is closer to twelve, and the extra six weeks are largely your own team writing down what they know. That work belongs on the plan, visibly, because hiding it is how these projects slip.
Ask three questions of anyone pitching you an internal agent. What are the forty questions it must answer correctly, and who wrote them? What exactly can it change, and who approves each change? And when it does not know something, what does it say? Vendors who have shipped this will have crisp answers. Vendors who have only demoed it will talk about the model.
At Bitcot we run these builds through our AI Development Lifecycle, which puts the evaluation set before the code, keeps the write surface deliberately thin, and makes the audit record a launch requirement rather than a later phase. It is a slower first four weeks and a considerably faster second quarter.
Frequently Asked Questions
What is a company brain in AI terms?
A company brain is an agentic system that answers operational questions and takes limited, approved actions across a business. In practice it is not a single agent. It is a portfolio of narrowly scoped focused areas, such as hiring operations or delivery operations, sitting on a shared substrate of routing, policy enforcement, audit logging and evaluation. The substrate is built once and reused, which is why the second focused area costs roughly a third of the first.
How do you build a company brain agentic system?
Build the shared substrate and the first focused area in parallel over twelve weeks. Weeks one to four cover the routing layer, policy gate and audit log on the engineering side, and the written policy vault on the business side. Week five writes the evaluation set of forty golden questions before any agent exists. Weeks five to eight build to that evaluation set. Weeks eight to ten run a read-only pilot with fewer than fifteen people. Weeks ten to twelve add one write action behind a draft, preview and approve gate. The second focused area follows in roughly five weeks.
What is a focused-area AI agent?
An AI system scoped to one bounded operational domain, defined by four things: a named set of structured data sources, a named set of documents, an explicit and short list of write actions, and a fixed evaluation set of questions it must answer correctly. Anything outside those four boundaries is out of scope, and the agent is built to refuse rather than guess.
How is this different from connecting ChatGPT or Claude to our company data?
A general assistant pointed at everything has no definition of correct. A focused-area agent has a fixed evaluation set written before the build starts, a deterministic computation path for numeric questions, a policy corpus that is version controlled and human edited, and an audit record for every answer. The difference is not model capability, it is scope, evaluation and governance.
Do we need PromptQL, or will a vector database work?
Vector retrieval is the right tool for unstructured policy and playbook text. It is the wrong tool for questions whose answers are computed, such as requisition age, accrual balance, sprint velocity or cycle time. PromptQL addresses that second category by having the model write a query plan that then runs deterministically as code outside the model. A mature semantic layer over your warehouse can serve the same role if you already have one.
How long does the first focused area take to build?
The engineering is roughly six weeks for a scoped read path plus one approved write action. Teams that quote four weeks are not counting evaluation. The realistic calendar to a trusted internal launch is closer to twelve weeks, because half the work is your team writing down policy that currently lives in people’s heads. The second focused area is materially faster because the router, approval gate, audit log and evaluation harness already exist.
Is an HR AI agent legally risky?
It depends entirely on what you let it touch. An agent that answers questions about policy and computes operational facts sits in low-risk territory. An agent that screens, ranks or scores candidates or employees enters EEOC scrutiny, state AI hiring audit laws and potentially EU AI Act high-risk classification. The boundary between information and decision should be written into the system prompt, enforced in the action list, and tested in the evaluation set.
Can the same architecture work for project management?
Yes, and project management is often an easier second area than HR. The facts are already structured in Jira, Linear or Azure DevOps, the recurring artifact is obvious in the weekly status report, and the blast radius of an error is a corrected document rather than a compliance event. The same router, approval gate and audit log carry over unchanged.
