The knowledge layer is not your moat. Your agent is.

If you are building AI agents for other companies, you have probably hit the wall we keep hearing about. The agent is great in the demo. Then you deploy it into a real customer and it starts getting their own rules wrong. Not because the model is weak. Because it does not actually know how that company works.

We have talked to founders building agents for logistics, claims, support, procurement. The pattern is the same every time. The hard part stopped being the agent a while ago. The hard part is the company knowledge underneath it, and keeping that knowledge true.

The part you did not sign up to build

When you deploy an agent for a customer, you inherit their process. Their approval thresholds, their exceptions, the way they actually handle the messy case. Almost none of it is written down in one place. It lives in a Slack thread, an email from finance, a senior person's head. So you capture it by hand, in onboarding calls and config files, and you ship.

Then it rots. The customer changes a rule in a Slack thread on a Tuesday and tells no one. Your config still says the old thing. Your agent acts on it, confidently, and now it is your name on the wrong action. You did not sign up to be the team that keeps every customer's tribal knowledge current. But that is the job the agent quietly handed you.

Knowing the customer is your moat. Keeping it current is not.

Here is the line we think matters. The agent you built, the domain insight, the way you turn a customer's process into something automatable, that is your moat. Nobody should touch that. But the plumbing underneath it, reading where the decisions live, turning them into something the agent can load, and re-deriving it the moment the source changes, that is undifferentiated. Every agent company is rebuilding it, badly, and it still rots.

That is the part we think you buy instead of build. Not because you could not build it. Because it is grunt work that is never finished, and your engineers should be on the agent, not babysitting a Slack scraper that goes stale.

Why every line is cited

A knowledge layer you cannot trace is one you cannot trust, especially when an agent is about to move money or close a ticket on it. So Lore puts a citation on every rule, pointing back to the exact message that set it. When that source changes, the rule re-derives, and the old version is kept and marked superseded for audit. The agent always knows which rule is current, and it can prove where it came from.

And it runs in your own database. The customer's data never leaves their infrastructure. For anyone in claims, finance, or health, that is not a nice to have, it is the whole conversation.

Keep the agent. Keep the moat. The thing that rots underneath it is the part to hand off.

We run it on ourselves

Our own company runs on three cited skills today: refund-handling, written from 47 real observations, incident-response from 41, and pricing-exceptions from 38. Every clause is clickable to the message where it was decided. We would rather show three you can audit than thirty you cannot.

We are early, in YC-review build, and we are onboarding the first design partners by hand, one real workflow at a time. If you are building agents and the knowledge underneath them is the part that keeps breaking, that is exactly the conversation we want. We are building in the open.