Short answer
Take a labelled checkpoint of the knowledge it will touch, before it has write access. BCG found 42% of companies expect agents to decide without approval by 2030 and only 5% have the controls. A whole-vault checkpoint you can roll back is the one control a small team can install this week.
Most of the argument about agent governance is about the moment an agent decides something. Almost none of it is about the moment after, when the thing it decided is already written into the documents your team works from, and nobody can tell what changed.
What did BCG's Applied AI Index 2026 actually find?
Boston Consulting Group published its Applied AI Index 2026 on 30 September 2026, built on a survey of 1,330 CxOs and senior leaders across more than 20 sectors. The headline number is that roughly half of companies now report real value from AI: 7.5% that BCG calls "future-built" and a further 41% "scaling", against 47% "emerging" and 4.5% "stagnating".
The number worth stopping on is further down. BCG reports that 42% of companies expect to grant agents genuine autonomy by 2030, meaning decisions taken without human approval, while only 5% have the full set of six controls BCG's framework asks for today. Companies with all six reported three times as much agentic AI value as those without.
Two more figures set the pace. AI spending has gone from about 1.7% of revenue in late 2025 to 3.3% now, roughly doubling in under a year, and more than 80% of it now sits outside the enterprise IT budget.
Worth saying what this is and is not. These are executive self-reports, not audited accounts, which BCG is upfront about. Nobody verified that the 5% genuinely have the controls or that the 42% will follow through. Treat the gap as a direction, not a measurement. It is still a wide gap, and it is pointed at a specific, mundane problem.
What does an autonomous agent actually touch first?
Not the money. Not production. The documents.
Before an agent is trusted to approve an invoice, it gets pointed at the team's written material, because that is the cheapest thing to give it and the lowest apparent risk. It summarises the specs. It updates the runbook. It files the meeting notes. It tidies the folder nobody has tidied since March. Every one of those is a write, and for most teams the first autonomous writes an agent is allowed to make are into the knowledge base.
That is also where the damage is quietest. If an agent breaks a deploy you know within minutes. If an agent rewrites forty notes over a weekend, flattening three folders into one and deciding that a decision your team reversed in March still stands, nobody notices until someone goes looking for a note that is no longer where it was. There is no alert for a wrong document. There is a person, weeks later, acting on it.
So the control that matters first is not a policy about what the agent may decide. It is whether you can put the knowledge back the way it was. That is a question about where the knowledge lives, which is why it is the question Baalda is built around, and it has a dull mechanical answer rather than a governance one.
Why does an export not count as an undo?
Most teams think they have this covered, and they are usually thinking of one of three things.
Backups of the whole workspace, which exist but take a support ticket and a day to restore, and restore everything, so you lose the week's real work along with the agent's mess. Per-page version history in a wiki, which is per page, so unpicking a reorganisation that touched forty of them means forty manual restores and a guess at the original folder structure. Or an export, which is a copy of the current state, including the damage, taken after the fact.
None of those is an undo. An undo has to be cheap enough that you take one before you hand over write access, and whole enough that one action puts the structure back, not just the text.
Baalda's version is deliberately unclever. Baalda is a team second brain made of plain markdown files on your own disk, edited by several people at once over a CRDT, served to any MCP client so an agent reads and writes the same files a person does. On top of that sits checkpointing: a checkpoint captures the whole vault at once, every note's content and the folder structure together. One is taken automatically each day the vault changes and the five most recent are kept, or you can label your own before a big reorganisation. Reverting rolls every member's vault back and broadcasts the change live.
"Or you can label your own before a big reorganisation" is the line that matters here, because handing an agent write access to a vault is a big reorganisation. You label a checkpoint, you connect the agent, and the worst case stops being a forensic exercise and becomes one revert.
What does that look like in practice?
The agent reaches the vault over MCP, which is the same connection a person's editor uses, so the write path is not a special integration with its own rules:
{
"mcpServers": {
"baalda": {
"url": "https://api.baalda.com/api/mcp",
"headers": { "Authorization": "Bearer mcp_your_token_here" }
}
}
}Connected, the vault arrives as tools: list_notes, read_note, search_notes, create_note, update_note, append_note, edit_note and the rest. The sequence for giving an agent a job it will do unattended:
- Label a checkpoint on the vault before the session starts.
- Mint the agent a token. Baalda tokens are per person and carry that person's access, so a folder you cannot open is a folder the agent acting for you cannot read. Scope the run by scoping the person.
- Let it work. Writes go through the same CRDT document a human edits, so a teammate typing in a note the agent is writing to does not lose their sentence.
- Read the diff the ordinary way, in a text editor, because the vault is
.mdfiles in folders. - If it went wrong, revert to the label. Every member's vault rolls back and the change broadcasts live, so nobody is left on a stale copy.
Two smaller mechanics stop the common failure before it needs a revert at all. read_note returns a revision; pass it back as expectedRevision on a write and the write is refused if the note changed in between, rather than landing on top of what a teammate just typed. And edit_note works on anchors, each of which must match exactly once unless you deliberately set all, so an anchor matching zero times or twice refuses the whole call and writes nothing. There is no half-applied edit to discover later.
If the MCP part is new, a second brain over MCP covers the mechanics from the start, and the docs have the per-client specifics.
Where does a checkpoint not help?
Four places, and they are worth knowing before you lean on this.
It is whole-vault, not per-edit. Baalda's checkpointing is a safety net for a bad reorganisation, not a record of every keystroke. If what you want is "show me the exact paragraph this agent changed on Tuesday", a checkpoint is the wrong instrument and you should be reading the file in git or in your editor's own history.
Five is a short window. Five automatic checkpoints means roughly five days of a vault that changes daily. An agent that has been quietly wrong for three weeks is outside that window, and a labelled checkpoint only protects the run you remembered to label.
Reverting is blunt. It rolls the whole vault back, which means it rolls back the work your colleagues did in the same period. It is the right tool when an agent has made a mess across many files, and the wrong one when it has made a mistake in one.
It controls nothing outside the vault. Five of BCG's six controls are organisational: who signs off, how value is measured, what the escalation path is, how the workforce is planned around it. No notes application supplies those, and a vendor claiming otherwise is selling you a checkbox. Baalda covers the knowledge an agent reads and writes. That is one control of six, and it happens to be the one you can install this afternoon.
It is also fair to say where other tools win here. Notion has page-level version history that is genuinely finer-grained than a vault checkpoint, and if your agent only ever edits single pages, that is the better fit. Confluence has an approval workflow that Baalda has nothing like. If the thing you need is a human gate before a change lands, rather than a way back after it does, buy the gate.
Who should actually do this now?
Teams of five to fifty, which is where this bites hardest. Large companies have a change-management function and will eventually have BCG's other five controls whether they want them or not. Solo users can hold the whole state of their notes in their head and will notice an agent misbehaving within a day.
It is the team in between, the one where the AI budget is being spent outside IT by people who do not run migrations for a living, that is about to give an agent write access to the only written record of how the company works, with nothing behind it.
The gap BCG measured is real, but it is not mysterious, and it does not need a framework to start closing. Most of the reason that only 5% have the controls is that the controls on offer are expensive, organisational, and take a quarter. One of them is a labelled snapshot and a revert button, and the real question is whether your team's knowledge lives somewhere that can offer you one. What a team second brain is covers why that somewhere should not be a chat transcript, and the companion question of whose disk an agent's memory sits on is its own post.
Take the checkpoint before you hand over the keys. It costs nothing and it is the only part of this you can finish today.
