- 10When are specifications not enough?
- 11Where is the state of the work kept?
- 12Who prepares a change before coding starts?
- 13What does impact analysis tell you, and when does it run?
- 14How do coding agents use the graph?
- 15How is each change checked, and how does the graph stay current?
- 16Who decides which work agents do?
- 17How do managers see what people and agents are doing?
- 18What happens across many products?
- 19What about existing systems and technical debt?
- 20What changes for the team?
- 21What results have teams seen?
Home / Follow the story / Scene 29: Products that agents use
Transcript
29. Products that agents use
Software products are starting to open their capabilities to their customers' own agents, which act on the customer's behalf through interfaces such as MCP servers. An MCP server that exposes hundreds of tools gives an agent access, and still leaves the agent to work out which tools to use, in what order and under which rules. The knowledge graph already records what the product provides: its capabilities, workflows, entities and contracts, which are the domain invariants every customer shares. An interface for agents can be built from the graph, describing each capability in the terms of the domain, independently of the screens and APIs designed for people. The graph also governs which external agent may use which capability. A formal grammar above the graph adds the rules a schema cannot express, so an agent can write what a customer needs and check its own result by running tests. Dialect engineering is the name for this approach, which lets more of a software-as-a-service product vary per customer while the domain invariants stay shared. Dialect engineering is set out at dialect-engineering.ai, and it builds on a knowledge graph governed with Semantic Engineering.
On the site: Graphs for Agent-Facing Products
Choose a path
The full video in six parts and an appendix, one part at a time.