Memory for Knowledge Work

Picture a routine task: you ask your AI assistant to draft a reply to a supplier chasing an invoice. The assistant gets the job done in seconds, except your company pays on 60-day terms and the assistant assumed 30. You correct it, the reply goes out, the task is done. Next month a colleague asks the same assistant a similar question, and it makes the same assumption.

The correction you made was real knowledge about how your business works, but it got lost when the session closed.

AI assistants have become part of how business gets done. Microsoft Copilot, Claude, and ChatGPT now sit alongside email and spreadsheets in the daily toolkit, drafting documents, answering policy questions, preparing analyses. They arrive capable and generic, and everything specific to your operation, from payment terms to approval chains to the exceptions accumulated over decades, has to be supplied, task by task, by the person doing the work.

Why your assistant stays generic

Assistants are gaining memory features, and those help with part of the problem. An assistant that remembers your role, your writing style, and your preference for short answers is more pleasant to work with.

The knowledge that helps with business tasks is of a different kind: how the expense policy applies to contractors, which system holds the customer record, last quarter's discounting decision. This knowledge is shared across a team rather than personal to one user, it changes as the business changes, and someone has to decide who can see it and when it stops being true. Personal memory features were never designed for knowledge that is shared, evolving, and governed.

Can an assistant learn this kind of knowledge on the job, from the corrections people are already making?

The evidence says yes

Our recent study, Learning on the Job, tested exactly this setup, on work that looks a lot like everyone's job. The tasks came from the banking domain of τ-bench, simulating customer-service work in a retail bank: look up the policy, follow the procedure, handle the exception. This is representative of most knowledge work, and it is hard for AI: even the latest frontier models, searching the bank's policy documents, only succeed on around a quarter of attempts.

We paired the models with Spark, our shared memory layer. After each task, the agent receives feedback of the kind a QA check or a reviewer produces, correcting its output. It then reflects and distils that correction into a lesson that can be reused the next time a similar situation arises.

Learning from those corrections took a frontier model from around a quarter of attempts to 40%, helping it solve tasks where the baseline had failed on every attempt. A smaller open-weights model, starting from a lower baseline, closed more than half the gap to frontier performance. The underlying model did not need to change in either case. The new competence came from the accumulated lessons, held in a memory that the organisation owns, written in plain language anyone on the team can read. This happened on everyday knowledge work, in a regulated industry, with nothing about the setup specific to coding. I covered the full findings in an earlier post.

Intelligence that compounds beyond code

Spark began with coding agents. Engineering teams were the natural first domain: their work produces constant feedback, and their tools were the first to adopt agents at scale. The banking study shows the learning mechanism carries over, and coding turns out to be one domain of many.

This is the idea we call compounding intelligence. Every correction, decision, and hard-won fix becomes part of a body of knowledge that the company owns. The next task starts from what the organisation already knows. Applied to engineering, it makes coding agents better. Applied to knowledge work, it reaches everyone whose day runs on policies, procedures, and judgement, which is most of the organisation.

For teams building their own internal agents rather than using off-the-shelf assistants, the same layer applies. The memory sits outside any one agent, so every agent you build draws from, and contributes to, the same body of knowledge. This comes with built-in provenance on every lesson and control over who can use what.

The Knowledge Work domain of Spark

This is the release I am most excited about since we started the company. We have taken what we learned building memory for coding agents and built a new Knowledge Work domain for Spark: shared memory for the business tasks that fill the working day. It will become generally available soon, and it works with the tools you already use, including Microsoft Copilot, Claude, and ChatGPT, as well as with agents your teams build themselves.

Your assistant learns your payment terms once. Your team's corrections stop being repeated effort and start being an asset. The organisation gets smarter with every task its agents run, with every manual correction, and with every piece of feedback.

An invitation

Before the doors open, I want to hear from people who see this problem every day. What do you find yourself re-explaining to your assistant? What should a memory for knowledge work do first? Which tool would you want it working in?

Please get in touch if you have views on any of these, if you have a particular use-case in mind, or if you just want to hear more about getting your agents to learn on the job.