Agentic Engineering & ToolingLunch Talk40min
Agents Shouldn't Control Control Flow
A deterministic compiler turns an enterprise context graph into governed agent workflows in Java, with control flow treated as a build artifact. The LLM only writes summaries, while code passes through Git, CI, tests, and human review, reducing hallucination risk and enabling policy-controlled changes.
talk.summaryAiDisclaimer
Jeremy AdamsNeo4j
talkDetail.whenAndWhere
Thursday, October 8, 12:55-13:35
TBA 4
talks.roomOccupancytalks.noOccupancyInfo
Compiling governed agent workflows from an enterprise context graph
An agent's control flow should be a build artifact, not a runtime decision.
Most agent talks show how to build an agent. We ask what your architecture review will ask: who decided that this agent is allowed to call the security platform, and what happens when that policy changes?
Imagine that our goal is to assess our company’s exposure (overall risk) for a customer using an enterprise context graph as the source of truth. Think of it as a semantic CMDB of systems, capabilities, policies, permissions, and MCP tools. Then a deterministic compiler projects a business operation from that graph into LangChain4j code. The generated workflow goes through git, CI, tests, and human review like any production artifact. The process is almost 100% deterministic: the LLM agent just writes the summary report.
The LLM does not redesign production control flow at runtime. Why add hallucination risk to a workflow designed to estimate risk?
The familiar generate, review, ship pattern reacts to authoritative enterprise decisions recorded in the graph. But the changes don’t take effect until they are tested and approved.
Attendees to this intermediate talk will come away with an intro to knowledge/context graphs and the enterprise knowledge layer, plus a live demo and git repo showing the pattern in Java.
An agent's control flow should be a build artifact, not a runtime decision.
Most agent talks show how to build an agent. We ask what your architecture review will ask: who decided that this agent is allowed to call the security platform, and what happens when that policy changes?
Imagine that our goal is to assess our company’s exposure (overall risk) for a customer using an enterprise context graph as the source of truth. Think of it as a semantic CMDB of systems, capabilities, policies, permissions, and MCP tools. Then a deterministic compiler projects a business operation from that graph into LangChain4j code. The generated workflow goes through git, CI, tests, and human review like any production artifact. The process is almost 100% deterministic: the LLM agent just writes the summary report.
The LLM does not redesign production control flow at runtime. Why add hallucination risk to a workflow designed to estimate risk?
The familiar generate, review, ship pattern reacts to authoritative enterprise decisions recorded in the graph. But the changes don’t take effect until they are tested and approved.
Attendees to this intermediate talk will come away with an intro to knowledge/context graphs and the enterprise knowledge layer, plus a live demo and git repo showing the pattern in Java.
Jeremy Adams
Jeremy one of those curious folks with both a technical and a strategic streak. Passionate about people and entrepreneurship, integration and automation. Through technical/business roles at Neo4j, Dagger, GitHub, Twistlock, and Puppet, Jeremy has both zoomed in and zoomed out a lot, acquiring an appreciation for the details and an ever-broader sense of the big architectural picture.