SEAM has been a journey through a question that keeps coming back in my work: how do people and systems know they mean the same thing?
Connecting an agent to a system gives it a route to information. It still needs to understand what the information represents, how things relate and which definitions apply. A familiar word such as “customer” can conceal quite different meanings.
SEAM stands for Semantic Entities, Associations and Metrics. The work sits within Measurelab, and this is my account of one important part of its evolution: getting clearer about which pieces were doing which jobs.
When the pieces sat together
The earlier approach included a shared gateway between agent workflows and source systems, alongside a registry of definitions. That brought questions about meaning and questions about access into the same piece of infrastructure.
There was useful work in there, but they were different responsibilities. Describing an entity, relationship or metric isn't the same as retrieving its latest value. Explaining how to do a task isn't the same as executing it.
The separation that mattered
The direction we settled on kept the Definitions and Map, and moved live access towards direct connectors in place of the old gateway.
Definitions describe meaning and identity. Skills describe how to carry out a task. Connectors reach the current information or perform an authorised action. The Map gives a person a way to see how the definitions fit together.
That distinction helped me see what was worth keeping without requiring every task to pass through a separate SEAM service. I didn't want to remove one intermediary only to build another with a different name.
Making the meaning inspectable
The definitions are kept in version control, with changes reviewed before they become the current version. The Map is a generated, read-only view of that material. It isn't a second database to keep in sync by hand.
That matters for both people and agents. A person should be able to inspect the meaning the agent has been given, challenge it and trace a correction back to its source. A diagram on its own doesn't provide that.
The work also included packaging definitions for use by agents, moving workflows towards ordinary skills and maintaining the generated indexes and reference material around them. The separation on a diagram still had to be followed through in the working instructions.
What the journey clarified
A definition file can be structurally valid and still contain the wrong meaning. A map can render correctly while describing something out of date. Neither result proves that an agent will answer a business question correctly.
Definitions also aren't an executable query engine. Models and code still have to implement the calculation; the answer still needs to be tested against the question and the underlying evidence.
That has pushed my interest towards the practical work around meaning: agreeing definitions, showing relationships, assigning ownership and noticing when the records stop matching reality. There is a connection here to the drift-watch experiment.
What I'm carrying forward
The useful outcome is a clearer approach to consulting, training and implementation, with definitions and reusable methods that can sit alongside the systems people already use. This page isn't announcing a standalone SEAM platform.
There is still work in keeping definitions accurate, verifying the workflows that use them and checking whether they improve answers. I don't want to turn a change of architecture into a claim that those questions have all been solved.
For me, the lesson is that simplifying the machinery can be progress. The original question about shared meaning remains worth pursuing, even as the shape of the software changes.