How I make company context move automatically across six systems
I'm a freelance AI engineer. The valuable part of this system isn't another agent or search box. It's the mapping layer between the systems where a company already works.
I built an operational context layer for a DACH B2B company. A page, thread, ticket, deal, mailbox item and meeting can all describe the same customer in different words. The knowledge graph maps them to one customer record, tracks which change is current, and keeps the source passage with every fact.
The part people used first was automatic sharing. Someone switches it on once. From then on, a decision accepted from their meeting reaches exactly the team it concerns within minutes, without needing to map from meetings with arbitrary topics to a system of record.
The test is simple: can someone who missed the meeting learn what was decided without asking anyone?
The control model makes that possible without turning the graph into a data free-for-all. Every read runs as the person asking. Anything they cannot open is dropped without a count. A fact reaches the graph only through a person's verdict or standing consent. Every write-back to tickets, wiki or chat waits for a human tap, including writes proposed through MCP. The same signal never opens a second review; a decline is stored; rollback compensates instead of deleting history. HR and employment data never travel.
What I got wrong at first: I thought the human gate would be the value people noticed. Nobody argued with it because it answered the accountability question. But it was the price of admission. The thing that changed daily work was the mapping: one decision could move from a meeting into the right team's context automatically, with the source and owner still attached.
If you build across company systems, where does your mapping break today: identity, permissions, conflicting records, or deciding who should receive a fact?
Full write-up with synthetic screens:
https://renezander.com/case-studies/operational-context-layer-governed-actions/?utm_source=indiehackers&utm_medium=community&utm_campaign=operational-context-layer
The strongest part is the “missed meeting learns what was decided” test. To make this defensible in a launch or sales conversation, I’d instrument three numbers: time from decision to the correct destination, the percentage of decisions needing a human reroute, and rollback/review rate. Then sell the delta on one workflow before expanding to six systems. Permission-aware writes and source lineage build trust; the measurable reduction in follow-up and duplicate work is what turns it into budget. Nice framing.
Keeping the source passage and decision owner attached to each decision seems more useful than a generic company memory. I run into a smaller version of this with DictaFlow, where context needs to stay inspectable instead of turning into a black box. I'd add a visible "why you got this" line to every routed update, along with the rule that matched and the original decision. People are more likely to accept automation when they can see why it reached them. They should also be able to turn off one noisy rule without disabling everything. The missed-meeting test is a good one.
thanks. the point is people say they would take away people from doing other important work. more so, in practice information gets more lost then theory allows. people are NOT all native to ALL tools. sb posting in teams does not walk into all systems - information never makes it to places it needs to have.
The mapping seems to be the real value. Have you measured whether teams actually spend less time chasing decisions and context after introducing it?
i do measure the kg. i measure decisions and if the chain of records did (proven) make better decisions in the future. only if i can prove information was available that led to a better decision that would not have been available otherwise (outside the kg) is when people can understand the value add.
That’s a much stronger value test than simply measuring time saved — especially if you can prove the information changed a decision. I’d be interested in digging into what those decision changes actually look like in practice. If you’re open to it, what’s the best email to reach you on?
cheers! my email is rene@renezander.com
Thanks! I’ve just sent it over.
Looking forward to hearing your thoughts whenever you have a chance.
One practical rollout pattern is to start with one decision type and one destination team, while keeping the old handoff running for a short overlap. Compare both paths on freshness, incorrect routing, and time-to-owner before expanding; that surfaces permission and identity gaps without making six systems part of the first test.
The question you asked at the end is the revealing one: "where does your mapping break — identity, permissions, conflicting records, or deciding who should receive a fact?"
That last category is where most teams actually fall apart. You can solve identity and conflicting records. But the moment you have to decide "should this context move to engineering or to sales," you've surfaced the actual team structure problem.
Most companies try to solve this by over-sharing everything to everyone. Your control model (read as user, write waits for tap) is backwards from how most tools think about it. But it's exactly right: the constraint forces you to encode who needs what, and that encoding becomes the operational definition of your team's actual responsibilities.
The automatic routing only works when that's clear. So the real product you built isn't the mapping layer. It's the forcing function that made the company write down what they actually do.
The person who missed the meeting is a useful way to explain the value. Having the source and owner travel with the decision means they can follow up without first reconstructing who said what. That part makes the workflow easy to picture.
The human tap before every write-back feels like the right boundary, especially with MCP in the loop. The tricky case sounds like conflicting records: I’d show the competing source passages side by side, keep the fact unresolved until someone picks one, and make that choice the audit event. That preserves the accountability you’re aiming for without hiding uncertainty.