Pipelines and agents

A pipeline is an execution flow that reads source data, transforms it, and loads the result back into a dataset or an ontology. A concept definition stays an empty model until a pipeline puts real rows into it.

An agent stands on the opposite side. It takes a natural-language request, decides which capability to call, and reaches the data through the ontology and the Semantic Layer. If a pipeline is the side that fills data in, an agent is the side that takes it back out.

The side that fills the model

A pipeline is built once and expected to run again and again. Reading the participation records, aligning types and formats, and loading into employee and project entities happens in the same order every time.

Whether repeated runs are safe depends on how the result is written. Loading in a way that updates rows sharing an identifier key means instances do not multiply no matter how often the pipeline runs; this is how entities and relations enter the ontology.

Writing into a dataset offers more options. Appending to the end piles up the same rows whenever the same range is fetched again, while replacing wholesale leaves nothing of the previous result. Any flow built for repeated runs has to settle this choice first.

Repetition extends to scheduling. Set a run time and the model stays current without anyone touching it, and the run history records what succeeded or failed and when.

The side that reads it back

An agent does not answer directly. It first decides what to call, and the targets fall into two kinds.

• Tools read or compute and return a result. They do not change outside state.
• Actors handle work that leaves a mark, such as recording, sending, or modifying. They can require human approval before running, or block the run.

The distinction is both a safeguard and a design principle. Reads may be repeated freely while state changes are hard to undo, so the two kinds do not travel through the same channel.

Where they meet when the question is about data

The two flows never call each other. When an agent has to answer from stored data, the model a pipeline filled becomes the evidence.

Not every agent takes this route. An agent built only from tools that compute or call outside services, or one that answers from documents, needs no ontology at all.

flowchart LR
    accTitle: How an agent querying loaded data meets a pipeline at the ontology
    accDescr: A pipeline reads the participation records and loads entities and relations into the ontology, and a question that must query the loaded data reaches the same ontology through the agent and the Semantic Layer.
    dataset[Participation records] --> pipeline[Pipeline]
    pipeline -->|load| ontology[(Ontology)]
    user[User question] --> agent[Agent]
    agent --> semantic[Semantic Layer]
    semantic -->|query| ontology

A pipeline loads the participation records into the ontology, and a question that must reach the loaded data arrives at the same ontology through the agent and the Semantic Layer.

While this route is in use, either side can change independently. Move the source to another system and only the pipeline needs work; change how questions are phrased and only the agent side is adjusted. Shake the ontology, on the other hand, and both sides shake with it. That is why settling the conceptual model first pays off.

The line between automation and judgement

Work that repeats under clear rules goes to a pipeline. Tidying the same source the same way every day leaves no room for human judgement.

The line appears where results persist. What to send and what to change depends on the situation and is hard to reverse. Putting an approval step on an actor is how that line is made explicit inside the system. Widening automation and preserving the points that need judgement are not opposites; they are decided together.