The phrase "shared context knowledge" keeps coming up in our client conversations, and I keep noticing it lands differently for different people. Worth pinning down, because I think it's what separates automation that works once from automation that compounds.
A working definition: shared context knowledge is the body of facts, rules, and history that every process in the company can read, write, and reason over, without re-discovering them on each run.
Sounds simple. It famously isn't, and two things seem worth writing down:
- what context has to look like to actually be shared
- why AI moves this from nice-to-have to urgent
The amnesia pattern
Take a normal week in a normal business and the same pattern shows up over and over:
- a flow runs, fetches some data, forgets it
- a second flow needs the same data, fetches it again, forgets it again
- a human holds the missing piece in their head and pastes it into the third tool
- next day, same loop
The system isn't dumb; it's amnesiac. Each automation runs as if it's the first one to encounter the world, and the expensive part isn't the work, it's the re-learning. What people supply when they step in manually is context: this customer is a VIP, this invoice goes through a special approval, this vendor pays in CHF whatever the contract says. Usually none of that is written anywhere a process can read. Until it is, automation has a ceiling.
Three properties of context that's actually shared
- Hybrid consumption. Context lives in structured form (customer master data) and unstructured form (a handover email, a scanned contract). A useful context layer reads both and exposes them through one interface: to processes, and to AI calling those processes. A system that only reads database rows is blind to half the company's knowledge.
- Flexible processes. Context changes: new customers, new rules, new regulators. Processes have to be parameterized by the context layer, not hard-wired around a snapshot of it. Define the rule once, in context; the processes consume it.
- Reachable without a project. A context layer that requires a six-month integration program is not a context layer (it's a data warehouse with a marketing budget). The valuable version is the one your processes can already reach.
Many tools do one of the three. A few do two. Doing all three in a way a non-engineer can keep extending is the hard part.
Where it naturally lives
This is one of the reasons I keep returning to the Process Execution Layer framing: if every flow already passes through one layer, that layer is the obvious place to look up the rules, read the customer record, enrich the input, and write back what the run learned. A pattern we like: every flow reads its inputs plus a context block, and writes its outputs plus a context delta. Over time the deltas become the company's working memory: not a database project, a side effect of running processes through one layer. This is roughly the direction flow8 is building in.
A concrete example (hypothetical, but a shape we see often): a small plumbing firm runs three processes: book the job, do the job, bill the job. Without shared context, booking re-asks the customer's address, the technician doesn't know the gate code, and billing doesn't know this customer pays in 60 days instead of 30. Three flows, three forgettings. With shared context, booking writes the address, gate code, and payment terms once; dispatch and billing read them. Same three flows, zero re-asking, and both the customer and the technician notice.
Guardrails, because shared knowledge can leak
Three worth building in from day one: lineage (every fact knows where it came from and when), access scopes (payroll context is not invoice-flow context), and expiry (some context is stale after a week: mark it). Done right, the same layer that gives processes their memory gives compliance a clean answer to "where did that data come from and who saw it?". Done wrong, it's a quiet data leak.
Why AI makes this urgent
An AI agent calling a process needs to know who's asking (role, entitlements), which entities are involved, which rules apply, and what's been done already. If that lives in nine systems and a few long-tenured heads, the model has to bluff (and it will, eloquently). If the context is shared and addressable through the same layer the AI uses to invoke processes, it doesn't bluff. It looks up, cites, and defers to the actual rule. And the same lookup is available to every other automation and report, which is where the investment starts compounding.
Starting small
Moves that pay off early, in our experience:
- run one process through the execution layer and make it write back what it learned: don't build a context layer from scratch, let one flow start depositing into it
- standardize entity keys (customer ID, account ID, document ID, etc): if your systems disagree on identifiers, context gets expensive
- add a small rules surface next to the processes (thresholds, approvers, eligibility) and have flows read from it instead of hard-coding
- treat the audit log as context too: the history of what the company did is itself a knowledge source, and a good execution layer gives it to you for free
None of this needs a strategy retreat; each item is a week or two of work. Curious what others have seen here: did your context end up in one layer, or quietly spread across a few?