There is much less consensus on how to build them at scale.

The common answer is to ingest company knowledge into a context layer. Load the documents. Index the policies. Embed the wikis. Connect the data catalog. Make the corpus searchable.

That is a useful start. It is incomplete.

A one-time dump can tell an agent what the company used to know. It cannot keep context current, curated, and useful for the agents that need it next week.

Finance makes this problem obvious.

Every finance team will have more agents. Building them well for production is hard, and it matters.

Some will explain variances. Some will prepare forecasts. Some will draft reconciliations, summarize contracts, or help with planning. What is less obvious is whether the hundredth agent is better because the first ninety-nine existed.

That will not happen if every agent carries its own private memory.

One forecasting agent misses the stakeholder note that explains why a region’s pipeline should be haircut this month. A planning agent cannot see the message that says a one-time vendor credit should be excluded from run rate. A scenario agent uses an old hiring assumption because the newer guidance lived in a thread. Each agent may be useful in isolation, but the company keeps paying the same context tax.

The durable advantage in finance AI is not the first useful agent. It is the accumulated context future agents can inherit: the assumption behind a forecast, the source choice behind a number, and the correction that prevents a stale answer. The architecture that makes that possible is a shared finance context layer.

Semantics tell an agent what a business term means. Context tells it how the business applies that term in the real world. Memory lets it use what prior work already discovered. If every agent builds those privately, the organization gets a larger set of isolated tools, not a finance AI platform.

Search and vector retrieval help agents find things. They do not decide which source is authoritative, whether an assumption is still current, whether a stakeholder note is safe to reuse, or how a correction from one workflow should change the next. The context layer has to do that harder work: each agent reads what the organization already knows, writes back what it learned, and leaves the next agent with a better starting point.

That is what context compounding means. The layer stores prior work in a form future work can trust.

Context Compounds Only Inside a Governed Runtime

Context only compounds when a later agent can trust what an earlier agent left behind.

That trust does not come from retrieval quality alone. It comes from knowing where a piece of context came from, what it was allowed to see, who produced it, when it was true, and why it is safe for the next agent to reuse.

The runtime supplies that trust boundary. In this architecture, the runtime is the governed environment where agents retrieve data, use tools, inherit permissions, write conclusions, and leave evidence. It is the line between local experimentation and material finance work.

Building still belongs close to the work. The person who lives inside headcount planning or revenue forecasting understands the problem in a way a central platform team usually cannot. Centralizing all building turns the platform into a queue.

Production execution is different. It needs one governed place. Without it, every builder picks their own data sources, secrets spread, access gets confused, outputs vanish into private logs, and the knowledge left behind is impossible to reuse.

The runtime has four jobs.

First, it controls sources. Each source needs an owner, a refresh cadence, a sensitivity level, and a statement of what it is fit for. Agents cannot discover finance truth by wandering through every table they can reach.

Second, it enforces permissions before context enters the answer path. An agent cannot carry the builder’s authority into every session. Access belongs at the retrieval and tool boundary, not as a filter after sensitive context has already been exposed.

Third, it scales controls by risk. Exploration needs speed. Decision support needs evidence. Anything that changes a system of record needs clear preconditions, approval where required, and a way to recover or reverse the action. One control model across all work either slows down harmless work or misses dangerous work.

Fourth, it preserves evidence. In finance, “it worked” is not an answer. A material output needs enough evidence to reconstruct the path: what context the agent used, what it did, who reviewed it, and what changed. If the number matters, the path to the number matters.

These controls are not the differentiator by themselves. They are the floor that makes the finance context layer worth trusting. Without them, context merely accumulates. With them, context can be inherited.

One Brain, Many Sources

The architecture is simple to say and hard to run: one shared brain, many sources.

Each agent writes to its own source. A reporting agent contributes reporting knowledge. A forecasting agent contributes forecast assumptions. A planning agent contributes planning decisions. Human business context can land in domain-scoped raw sources. Writes stay attributable, so one agent does not overwrite another agent’s contribution.

Reads are federated. When an authorized agent asks a question, it searches across the governed whole instead of staying trapped in private notes. A reporting agent can benefit from a forecast caveat. A forecasting agent can benefit from a planning assumption. A planning agent can benefit from an exception pattern discovered somewhere else.

This is where context starts to compound. A stakeholder instruction captured for one forecast becomes usable context for another workflow. A correction from one agent prevents a stale answer in another. A source caveat discovered during one analysis becomes part of the retrieval surface for the next.

The shared layer is not one giant undifferentiated pile. Source matters. Trust tier matters. Sensitivity matters. Effective date matters. Whether something is raw, agent-written, curated, canonical, stale, or superseded matters.

But the mental model is still one brain, many sources.

That model avoids two traps. In the first, every agent has private memory and nothing compounds. In the second, everything lands in one shared bucket and nobody knows what to trust. The useful design sits between them: contributions stay attributable to their source, retrieval crosses sources according to permission and purpose, and the platform owns the compounding work.

Most Context Starts Outside the Agent

Agent output is only one input.

In finance, some of the most important context starts as a human instruction. A business stakeholder tells an analyst to adjust a forecast assumption. Someone explains that a demand signal is real but timing-shifted. A region leader says a one-time event should be excluded from a run rate. An operator shares why a metric moved, but the explanation lives in a message thread or in the analyst’s head.

The forecast changes. The reason often disappears.

The first problem is visibility, not AI. The governed context layer has to turn that operational business context into a visible, readable, reusable artifact.

The safe version is not “ingest every message.” That creates privacy risk, noise, and a giant pile of low-quality text. The stronger pattern is intentional context capture: route high-signal material through controlled landing paths, preserve provenance, redact sensitive material, and keep raw context low-trust until it earns promotion.

The landing path matters. A controlled inbox or tagged workflow can encode business domain more safely than asking a model to infer sensitivity from message content. Once captured, the context can be normalized, made findable, linked to relevant entities or topics, and reviewed for whether it is durable enough to elevate.

This is a very different posture from dumping communications into a vector store.

It creates a trail for the operational judgment that already changes finance work. The analyst’s forecast adjustment is no longer a silent spreadsheet move backed by a disappearing message. It becomes sourced, dated, scoped context that the forecast agent can use, the planning agent may benefit from, and a reviewer can inspect later.

That is how context gets out of people’s heads without pretending every message is knowledge.

Do Not Make Producers Learn the Dialect

One operator lesson matters more than it first appears: a producer does not have to learn the context layer’s dialect.

It is tempting to require every agent to emit perfect structured pages, exact links, canonical entity references, and beautifully formatted metadata. That makes the platform look clean in a design doc. It fails in the real world.

If the platform expects fifty different producers to learn its markup conventions, most of them will do it wrong. If unstructured sources have to comply with a linking scheme before they can participate, they will not participate. A meeting transcript, email thread, or analyst note will not politely format itself for your graph.

The better contract is lower-friction and more durable.

Producers throw useful content over the wall into their source. The platform makes it findable immediately. Then the platform compounds it asynchronously.

Immediate findability comes from retrieval, not perfect linking. Content can be chunked, embedded, indexed, and searched by meaning on day one. The graph is valuable, but it cannot be the ingestion contract. A graph that grows after ingest is an enrichment layer. A graph required before ingest is a tax every producer will fail to pay.

This distinction is easy to miss. It is also the difference between a platform and a boutique integration.

The producer’s obligation has to be minimal: identify itself, write useful content to its source, and follow the contribution contract. The platform carries the heavier work: make that content retrievable, enrich it over time, link it to the rest of the layer, and preserve evidence.

That split of labor is what makes the platform durable. It lets the context layer accept imperfect but useful inputs without becoming a junk drawer. It also lets the compounding machinery improve over time without forcing every producer to change.

The Contribution Contract

The contract is the part that is easiest to underestimate.

Every agent connected to the layer has to do two things.

First, read before it computes. Before an agent uses a metric, chooses an assumption, explains a variance, or drafts an answer, it has to ask the shared layer what the organization already knows.

Second, write back what it concludes. If a run produces a durable decision, assumption, signal, anomaly, or semantic clarification that another finance person or future agent would still care about in six months, it has to go back into the layer.

That six-month test is a useful filter. It separates knowledge from exhaust.

Raw logs are not knowledge. Scratch work is not knowledge. A vague summary is not knowledge. A duplicate fact written under a new name is not knowledge. A durable conclusion with source, as-of date, confidence, and rationale might be.

The contract also has to say: reconcile, do not fork.

If an agent learns something about an existing forecast assumption, exception, or source caveat, it has to update or extend the existing context path rather than create a parallel explanation. Silent forks are how a context layer rots. The same business judgment starts appearing in slightly different forms, with slightly different scopes, until nobody trusts any of them.

No freeloaders, no noise.

A read-only agent takes from the layer and gives nothing back. A write-only agent dumps output without grounding itself in what already exists. Both break the flywheel.

The contract makes every agent both a consumer and a contributor. Reading without writing improves one run. Writing without reading adds noise. Reading first and writing back durable conclusions makes the shared context better after every useful run.

Making It Operational

The layer cannot start empty.

An empty context layer creates a bad first impression. The first agents ask it questions, it has little to say, builders decide it is optional, and the platform never becomes the default path. The compliant path has to be useful before it asks for discipline.

The operating sequence starts with a small trusted seed: semantic authority, source guidance, and curated business context.

Semantic authority means the core metric definitions, dimensions, grains, source bindings, and ownership are already in the layer. The goal is not to model every concept in finance. Start with the handful that many agents reuse and that create the most damage when handled inconsistently.

The source guide is the practical version of source binding. The layer needs to know which sources are authoritative for which concepts, what each source is fit for, how fresh it is expected to be, and who owns it. An agent does not have to guess whether a table, report, or document is the right place to answer a question.

Curated business context gives the first agents something useful to retrieve on day one. A few policy-style pages can be more valuable than a thousand raw documents: how one-time items are treated, how planning assumptions are interpreted, what exceptions are common, and which caveats matter.

Then load one real corpus, not the whole company.

The first corpus has to be narrow enough to curate and broad enough to prove the pattern. The point is not coverage theater. The point is to exercise the loop: ingest content, make it findable, retrieve it in real work, identify gaps, correct bad assumptions, and promote useful conclusions.

This is also where the operating model begins. The source registry is part of the product, not an admin afterthought: owners, trust tiers, exclusions for content whose access controls are not ready, a correction queue for curators, and a lightweight health check showing whether agents are reading before they compute, writing back useful conclusions, and producing raw exhaust to reject.

The first few agents have to use the same contract every later agent will use. A pilot that bypasses the contract teaches the wrong lesson. Even if the first version cannot enforce the whole future architecture, it can rehearse the shape of it: read through the shared context layer, write to scoped sources, and emit enough telemetry to prove the layer is being used.

The bootstrap is successful when the layer starts pulling work toward itself. Builders use it because it has the definitions they need. Agents read it because retrieval improves their answers. Curators improve it because corrections are visible. Future agents connect because the path is easier than inventing a private brain. The first agents do not only consume the seed; they make it more valuable.

At that point, the platform starts becoming operational.

The context layer has to resist rot

A context layer can fail while it is growing.

More pages, more embeddings, more graph nodes, more telemetry, and more agent contributions can still produce a system people trust less every month.

The failure modes are predictable.

A curated policy and a raw agent note can start to look equally credible. A forecast assumption from two quarters ago can be retrieved as if it were still current. Two pieces of business context can disagree while the system quietly lets the newest one win. Sensitive context can enter the answer path before permissions are applied. Low-confidence agent output can land directly in shared truth because there is no draft, review, or promotion state.

These are not edge cases. They are what happens when a useful context layer has no operating model.

Trust tiers keep raw contributions, generated findings, reconciled control results, drafts, and canonical knowledge from collapsing into the same retrieval surface.

Temporal reasoning keeps time from disappearing. The system must know when something was effective, when it was recorded, when it became stale, and what replaced it.

A conflict model keeps last-write-wins from becoming finance policy. Some conflicts block promotion. Some create a curator task. Some coexist because they apply to different periods or scopes. Some become correction records that preserve the original conclusion and the reason it was superseded.

Curation has to be an operating role, not a casual side chore. Someone or some governed workflow has to decide which knowledge becomes canonical, which conflicts matter, which stale material decays, and which corrections preserve history.

Without those controls, the layer becomes a searchable graveyard. It still has content. People stop trusting it.

Once that happens, agents route around it, and the compounding loop is dead.

Keep Telemetry Out of Truth

The platform also has to separate the signals it observes from the knowledge it trusts.

Every agent interaction creates useful telemetry: what was asked, what was retrieved, what was accepted, and which corrections came back. That telemetry shows where the context layer is weak. Repeated unanswered questions point to missing business context. Repeated corrections point to stale or ambiguous sources. Retrieval failures can reveal context that exists but is not packaged well enough for agents to use.

But raw telemetry cannot become knowledge automatically.

The cleaner model separates knowledge agents can retrieve and cite from usage signals that help operators improve the layer. Raw logs can reveal sensitive behavior. Behavioral signals can identify gaps without being reliable business facts. Insights mined from telemetry have to re-enter the context layer through curation, not seep into it as raw exhaust.

Cost belongs in the same operating frame. At platform scale, many agents, retrieval calls, embeddings, evaluations, and evidence trails create real spend. Make that spend visible, tie it to value, and retire agents that do not earn their keep. Cost controls can shape routing, caching, batching, and ceilings, but they cannot lower the rigor floor for material finance work.

The Bet

Every finance team will have more agents across planning, forecasting, reporting, reconciliation, and decision support.

What separates one finance team from the next is whether each of those agents leaves behind something the next one can trust.

One stakeholder instruction becomes dated context for a later scenario. One forecast assumption becomes reusable context for planning. One correction prevents a stale conclusion from spreading. One exception pattern becomes a signal another agent can use. The output of one agent becomes the starting point for another, with its evidence intact.

This is the compounding loop: context improves because work happened, and future work improves because context improved.

It is a bet, not a victory lap. The early version of this architecture is mostly about structured context capture: definitions, assumptions, decisions, and the traces that justify them. The richer organizational memory comes later, after the access, privacy, retention, and trust model can support it.

That sequencing is the point. Building the agents is real work, and it will keep mattering. What compounds is making one analyst’s agent leave behind something the next analyst’s agent can trust. That is what has to be built.

For this work, that is the test that matters. Look at how your most important reporting gets made today. The numbers that anchor QBRs, MBRs, and board reviews are still assembled by hand: built in spreadsheets a handful of analysts fully understand, reconciled the night before, wrapped in a narrative rewritten every cycle. Most large companies run some version of this, and the people who do it are very good at it. That is the constraint we set out to change.

The reason AI hasn’t changed much here is not the model. The rigor that makes the reporting trustworthy does not live in a system - it lives in those analysts’ heads. Point a model at scattered files and undocumented logic and you get plausible, confident, unverifiable answers: a better-looking version of the same problem. The fix wasn’t to point a model at the mess. It was to rebuild the foundation under it, from the source data up, and put it into production. The hard part was never the model.

The cost was never the hours

The obvious cost of hand-built reporting is the labor - a few skilled people, a week or two a cycle. Real, and small; no CFO will build the case on that alone. The expensive part is everything the business waits on while the work happens.

A sharp question raised in a review - why did that segment turn, what does it do to the forecast - rarely gets answered in the room; it waits for the next cycle, by which point the decision has often been made without it. The decision waits on the reporting instead of the reporting serving the decision. Rigor reaches exactly as far as the few people who hold it: the flagship review gets the careful hands, and the dozens of other QBRs and MBRs get a lighter version, or get it late. And the whole capability rests on those same people. When any of them is out, the reporting stalls - and the talent you’d most want shaping strategy spends its time assembling and reconciling instead.

So why hasn’t AI simply fixed it? Because finance holds a bar that doesn’t move: a fast wrong number is worse than a slow right one. Speed buys nothing here unless you can trust it, and trust is the one thing the hand-built process keeps in people’s heads rather than in any system. Point a model at that and you do not get finance-ready reporting; you get output no one can stand behind. The work was making the numbers provable on their own - so trust stops being something a person vouches for and becomes something the system can show. Only then does speed matter.

How it’s built

The diagram above lays out the architecture: five layers, data moving one direction, each doing one job before handing the result to the next. The lower layers are conventional, by design - a single door to the warehouse that caches and logs every query, and a compute layer where the logic for ARR, retention, churn, and expansion lives as tested code rather than in a spreadsheet only its author can read. That much already earns its keep: it gets the business logic out of people’s heads and into something the team can review. The parts that took the real work are the layer at the top and the spine down the right.

Start at the top. A semantic layer usually starts as a dictionary of definitions - net retention computed one way, everywhere. We have that, but it is the smaller half. The same layer also holds how we actually look at the business: which products roll up into which portfolios, how segments ladder together, the cut each leader wants to see, the priorities that change shape every quarter. That context usually lives nowhere but in a few analysts’ heads. Here it’s written down and governed - and that is what lets an agent re-shape the reporting on request. A new segment, a different leader’s lens, a new priority moved to the front: minutes, not a release cycle, and every number still reconciles to the same definitions. It was seeded from the existing BI semantic model, then extended with the part BI was never built to carry - the opinionated, current view of the business itself.

Down the right runs the machinery that makes the output provable rather than merely produced. The first piece is lineage. Every query and every number that lands on a slide is recorded - source, calculation, raw value, value shown - and it isn’t a log nobody opens. It ships with the reporting as an audit workbook, and because each run captures the data snapshot and the exact version of the code, any number in any past report can be reproduced months later. When a figure is challenged in a review, the answer is on the screen, not “let me check with the analyst and come back to you.”

The second piece is the one people find hardest to believe: the AI never touches a number. A model drafts the narrative, but it’s handed the already-computed figures and asked only for words; where a number belongs, it leaves a placeholder the system fills from the audited value. It’s kept away from the sensitive items entirely - it cannot see a financial correction, let alone make one. The language is generated; the numbers are not. That single rule is what lets a person sign an AI-written executive narrative.

The rest of the spine is governance and verification. Corrections run through a governed process - documented, attributed, reviewed - not quiet edits. And nothing ships until it’s checked twice: against a known-good version of the reporting to catch what moved unexpectedly, and cell-by-cell against the source of record.

A system with per-figure lineage, governed corrections, and cell-level reconciliation used to look like a platform team’s annual plan. The agent changed the size of the team required to build it, but not the discipline required to make it production-grade. The engineering became accessible to the people who own the reporting; the scarce part stayed the same: knowing what the numbers mean.

What it pays back

The obvious return is the analyst time handed back - a week or two a cycle. Real, and the least of it. The returns that matter don’t trim the old process; they change how fast, and how widely, the business can use its own numbers.

Decision velocity comes first. When the reporting is governed and regenerable, the loop from question to answer collapses. Take a complex revenue reconciliation - slow and manual, so it’s run once, globally; producing it for every region and segment by hand was rarely worth the effort. The system produced it at that grain in about an hour. The granular cut that used to earn “we’ll come back to you next cycle,” or never got made at all, now arrives in the room, correct, with the lineage to back it. The bottleneck stops being the production of the number and becomes the decision itself. Acting one review cycle earlier on a churn signal, a pricing problem, or a segment starting to slip dwarfs every hour of production labor combined.

Then self-service, which for executive reporting doesn’t exist today, because the only interface to the numbers is a person - and you can’t have your best analyst vouch for every figure every stakeholder pulls, so access stays narrow by necessity. Trust the system can prove is the kind that scales to many hands: the GM who wants her slice of the business her way can pull it herself, consistent with the official reporting rather than a side spreadsheet that quietly disagrees. And the role shifts with it - from the scorekeeper who assembles and reconciles to the advisor who interprets and recommends. The scarce talent that used to spend its best weeks assembling the reporting now spends them on the calls the reporting exists to inform: where the forecast is going soft and what to do before it does, which segment needs attention, where the business is changing faster than the plan. Production was never the highest use of those people; the decisions are.

The quietest return is integrity. One definition, used everywhere, ends the “whose number is right” argument between two reviews. The capability survives turnover instead of leaving with the person who understood the workbook. And a challenged number holds, because the lineage behind it was built in, not reconstructed after the fact.

Don’t we already have tools for this?

It’s a fair question, with two honest versions: isn’t this what BI is for, and couldn’t you get the same result by handing every analyst an AI agent? Neither closes the gap.

Take BI first. Modern platforms are good, and they overlap with parts of the system - a semantic layer, governed metrics, even natural-language queries. BI is not weak; it is built for a different job: open-ended exploration, current, with many people interrogating dashboards. Executive reporting is different - curated, point-in-time, carrying an argument, made to survive scrutiny months later. The proof is in what BI-equipped companies still do: assemble board reviews, QBRs, and MBRs by hand in the days before the meeting. If BI closed that last mile, that work would not exist at the scale it still does. A dashboard has no narrative, no governed treatment of corrections, and no audit trail for one number on one slide. BI feeds the reporting; it does not produce it.

So it’s built on BI, not against it. The semantic layer was seeded from the existing BI model, and the finished reporting reconciles back to BI as the source of record. It doesn’t model data better than a mature BI platform, and it doesn’t replace it; what it adds sits above - a narrative bound to audited numbers, governed corrections, per-figure lineage reproducible at its original vintage. For a CIO, that extends the BI investment into executive reporting instead of competing with it.

The other version comes from the opposite instinct: point an agent at a dataset, build a dashboard in two minutes, and conclude everyone just needs the tool. The agent is powerful - it’s the same kind of engine our system runs on - but aimed at raw data, it fails two ways. It’s fluent, not necessarily correct: it can build a clean, confident dashboard on a wrong join or the wrong snapshot date, so without a verification harness, faster generation can just mean faster wrong numbers. And nothing compounds: a bare agent re-derives the business from scratch each session, a little differently each time, so two people get two different churn numbers and none of it survives once the prompt is gone - a new dashboard every day, nothing canonical.

The work that matters is encoding the business once - definitions, framing, corrections, checks - into a governed substrate the agent runs on top of, instead of rediscovering it every session. Handing every analyst a raw agent is the data equivalent of letting every engineer deploy to production from a laptop: the value is in the discipline around it. The goal was never more dashboards, or faster ones. It was fewer canonical views anyone can trust.

What went wrong

The same speed that put answers in the room is also what broke the operating model - and that’s the part I’d warn anyone about. Once the teams saw they could get any cut they wanted, they wanted all of them - the night before the review. Route all those requests through the few people who run the system, and you’ve moved the old chokepoint one desk over, not removed it. The lesson was blunt. The speed only pays off if the teams who own the reviews can drive the system themselves. Making them self-sufficient on it wasn’t a line on the roadmap; it was the thing that had to work - or we’d have rebuilt the old constraint with better tooling.

What stays human

Because the system produces the reporting on its own, the fair question is whether the AI now decides what the company says about itself. It doesn’t. The system handles the arithmetic, lineage, and checks. People make the calls.

People still own what the numbers mean: what counts as retention, which customers are carved out, how the business is cut this quarter. The AI can suggest a definition; a person decides it, and the change is reviewed. Corrections to past numbers are a human act - entered, explained, and signed off by a person, with the AI not permitted near them. The narrative is drafted by the model but read and approved before anyone else sees it. And the read stays human: the system flags what looks off - a number that jumped, two figures that don’t tie, a check that failed - but never says what to do about it. What matters, and why, is a person’s call.

So the AI is never left alone with anything that reaches an executive review. It runs the routine work and raises its hand when something looks wrong; people hold the definitions, the corrections, the words, and the decisions. Full automation was never the aim - for executive reporting, it would be a mistake.

And the effect is more accountability, not less. When someone signs off on a number, they can show exactly where it came from and reproduce it on the spot - more than they could when the logic lived in a spreadsheet only they understood. Because the machine has already done the arithmetic, the review isn’t re-adding the columns. It’s the judgment: is this the right read, does the framing hold, is this the story we should be telling. That was always the part that needed a person.

Where this leaves us

Keeping executive reporting both current and trustworthy used to require the same thing it always had: a few people rebuilding it by hand every cycle, holding the rigor in their heads. That was the constraint - and moving the rigor into a system, provable and current by construction, is what dissolves it.

What that leaves is a layer most companies don’t have yet: a governed reporting layer between the BI tools that hold the numbers and the executive reviews that run on them - dynamic enough to keep up, provable enough to trust. BI supplies it, the business consumes it, and the system in between turns the last mile from manual into fast, traceable, and reproducible. It’s the piece the stack has been missing.

The lesson is the one we opened with: the hard part was never the model. Pointing AI at executive reporting is easy, and often disappointing. Building the foundation that lets AI produce reporting the business can trust is the actual work - and it’s worth doing. The models will keep getting better on their own. The trust won’t. That you have to build.