The prompt that keeps growing: why we're building a context layer for agents

You've been asked to build an agent that checks manufacturing batch records against the plant's SOPs. Data access takes a day. There's an MES API, you write a tool definition, and batch records come back as JSON. You paste the relevant SOP sections into the system prompt, run it on three batches, and it flags the right ones. The demo goes well.

Then the edge cases arrive. A moisture limit applies to one product family and not another. A step has to be signed by someone holding a particular role, so a name on the record isn't enough. Two SOPs overlap, and one of them takes precedence. "Released" means something slightly different at the second site. You fix each of these the quickest way available, with another paragraph in the system prompt.

By week three the prompt is a few thousand tokens. Most of it is business rules you transcribed from PDFs you've read once.

Look at those paragraphs closely and they describe a schema. There are entities (products, lines, batches, roles), relationships between them, constraints, and permissions. Because it's written in prose, it has no types, no versions, and no references back to the SOP clause each rule came from.

That causes three problems. You can't diff it against the source document. You can't write a check that a given rule is present and correct. And the model re-reads and re-interprets the whole thing on every call.

That's manageable for one agent. It stops being manageable with the second.

Say the next request is an agent that triages deviations. It needs most of the same knowledge: the same products, roles and escalation rules. So you copy the relevant parts of the first prompt, adjust them, and move on. Now there are two copies of the business rules, and they have already started to drift.

Six months in, a team can have ten agents, each holding its own version of how the business works. When an SOP is revised, someone searches through the prompts and hopes they caught every copy. When an eval starts failing, it's hard to tell whether the model changed or the rule changed. In code review, nobody can verify the business logic, because it's buried in prose that only the original author understands.

Retrieval is the usual next step. You chunk the SOPs into a vector store and pull the relevant sections at query time. That finds the right paragraph most of the time. But the agent still interprets it fresh on every call, and an exception clause two pages away can fall outside the top-k results. Retrieval also has no notion of identity. "Line 3", "Blister Line 3" and "L3" are three separate strings, and "QA approver" is a phrase with no permissions attached.

Agent frameworks handle orchestration: state, tool calls, hand-offs between agents, and retries. They're good at it, but they assume each agent already understands its domain.

Workflow builders let you model a process as steps. Someone still has to draw each process by hand and keep it in sync as the SOPs change.

Each of these belongs somewhere in the stack. None of them holds the business meaning itself, so that meaning ends up back in the prompt.

A context layer treats business meaning as a shared dependency, the same way you'd treat a schema or a shared library. It holds canonical identities for products, lines, materials and roles; the relationships between them; definitions and the rules that govern the work; and links to the source of each item, with timestamps and provenance.

Agents query a view scoped to their task instead of carrying the whole model in their prompt. The batch-record agent asks for release rules, product families and signing roles. The deviation agent asks for deviation classes and escalation paths. Both read from the same definitions, so they agree with each other without you keeping two prompts in sync.

The layer also keeps recorded facts, business rules and agent suggestions separate. A moisture reading is a fact, the acceptable range is a rule, and "this batch looks releasable" is a suggestion. An agent's output lands as a proposal and only becomes a commitment when someone approves it. Every flag can point back to the rule and the source it came from.

Your orchestration stays where it is, and now it has a consistent model to coordinate over. In practice, a rule changes in one place and every agent picks it up. Your system prompts shrink back to task instructions, and the business logic becomes something you can inspect.

Nobody wants to hand-write an ontology. Enterprise ontology projects have a reputation for months of modelling workshops and a model that drifts soon after it ships.

The spec already exists, though. Operations teams maintain SOPs, work instructions and process documents because regulators and auditors require them. What's been missing is a way to turn those documents into something an agent can use.

That's what Neuron does. You give it an SOP, a business rule or a process description, and it compiles that into a structured model of processes, roles, rules, objects and relationships. From there you can see what it compiled, attach data directly to the objects, start the runtime and build agents through the API, SDK or MCP, or export the model to use elsewhere in your stack. The first model is live in hours, not authored in months.

Back to the batch-record agent. The rules now come from the compiled model, and the prompt holds only the task. Each flag cites the rule and SOP revision behind it. When the SOP changes, you recompile, and every agent built on the model updates with it.

The first agent isn't dramatically faster to build. The second one is, and so is the tenth, because each starts from a model of the business that already exists. Your time goes into what the agent should do, and maintenance becomes a matter of keeping the source documents current.

That's the bet behind what we're building: teach the system the business once, and build every agent on it.

If you're building agents on operations and recognise the prompt that keeps growing, Neuron is open for self-serve. Bring an SOP and see what it compiles into.