JournalCompany
Introducing Knowledge Work
Knowledge Work is a new domain in Spark for the corrections, decisions, procedures and client rules that business work produces all day. Lessons keep their source and scope, survive a change of model or tool, and are tested by whether the second task gets better.
On Monday, an agent drafts a client update. It buries the blocker and turns a proposed delivery date into a commitment.
You correct it: decisions and blockers first; confirmed dates are commitments, everything else is an assumption.
On Friday, another agent prepares an update for a different client. It has different facts, a different model and a different interface. Does Monday's correction help?
I think that second task is the only test of whether an agent system is learning. The first task proves the agent can do some work. The second tells you whether any of that work made the organisation smarter.
Most agent systems still fail that test. The correction sits in a chat history, a trace or someone's head. The next agent starts from scratch and someone pays to explain the same thing again.
Today we're launching Knowledge Work, a new domain in Spark built for exactly this problem.
What we mean by knowledge work
Spark started with coding because code gives us unusually good feedback. Tests pass or fail. CI breaks. Reviewers leave precise corrections. You can tell whether an agent avoided a dead end it hit last week.
The rest of a company isn't quite as tidy, but it produces the same kind of learning all day.
A researcher learns that vendor blogs can point to a claim but cannot support it. A finance team changes how it defines revenue after a migration. An operations lead knows which approval path applies to contractors. A client team learns that one customer treats a proposed date as a promise while another does not.
These aren't general facts a better model will magically know. They are local judgements about how a particular organisation works, and they change.
Knowledge Work gives those lessons a proper home in Spark. Corrections, decisions, procedures, evidence standards, stakeholder context and working preferences can become sourced, scoped memories that future agents retrieve when they are relevant.
This is a new domain inside the same product, not a separate office assistant. Coding and Knowledge Work have different semantics and separate stores because a passed test is not the same trust signal as an approved policy, a reconciled account or a signed client decision. Both use the same underlying memory system, but Spark doesn't throw them into one giant bucket and hope retrieval sorts it out.
Reliability needs provenance and scope
The obvious version of agent memory is a growing pile of notes. That works for a while. Then two notes conflict, an old policy survives a reorganisation, or advice from one client quietly appears in work for another.
That isn't memory. It's liability with a search box.
Every Knowledge Work lesson keeps its source and scope. A private correction stays private. A client-specific rule stays with that client. Conflicting lessons can surface for review rather than silently merging, and stale knowledge can lose trust and be retired.
I don't care whether an agent sounds familiar. I care whether its next piece of work reflects what the team has already corrected, without smuggling old or irrelevant advice into the task.
The memory survives the tool
The model market is moving too quickly for a company's learning to live inside one provider.
You might use Claude for one task, an open model for another and a smaller model for routine work. Your agents might run in an IDE, a desktop client, an automation harness or something your own team built. Those choices will keep changing.
Spark sits outside them. It is model-agnostic, harness-agnostic and IDE-agnostic. Any supported agent connected to the same private space through MCP can use the lessons available to it. Change the model, harness or interface and the memory remains yours.
That portability showed up in our controlled banking evaluation. Correction-derived memory reached 2.6 times the single-trial success of a static-RAG baseline in the banking domain of τ-bench, and lessons learned with Mistral Large transferred to Claude Sonnet 5. The model weights did not change. The competence came from memory held outside them.
Faster, more reliable and cheaper
When an agent already knows the useful lesson, it doesn't need to repeat the investigation that produced it. It can avoid dead ends, take fewer steps and use less context to reach the answer.
We have measured that effect most extensively in coding, where repeated work became faster, cheaper and less variable as useful knowledge accumulated. I expect the same basic economics to matter in research and operations, but I'm not going to pretend a coding benchmark proves a percentage for every kind of office work. That is what the new domain now lets us test properly.
Reliability comes first. The speed and cost savings come from spending less time being wrong in familiar ways.
Available now
Knowledge Work is available in Spark alongside Coding.
Connect a supported agent to your private space, choose the Knowledge Work domain and give it something real: a correction you keep making, a procedure people regularly miss, or a judgement that never survives the meeting where it was made.
Then try a different but related task later. If the lesson doesn't improve that second task, storage has achieved nothing.
If it does, your agents have started learning how your organisation actually works.