How the Agent Harness governs actions
Product stage · Implemented building block
The Agent can propose an action. The Harness controls its tools, approvals, and audit trail.
What does “start monitoring” actually mean?
An approved permit is not yet monitoring. The permit says what was authorized on paper; it does not say whether the fire watch stayed in place at 3 pm.
Consider a hot work permit. A supervisor hands it to the Agent and says: start monitoring.
The quickest answer is to let the model call one function, such as create_monitoring_task, and consider the job done. That call would create a task. It would not know which rules apply, which devices are allowed, whether the permit is still valid, or whether the plan conflicts with another task.
Between the approved document and the running monitor, Lingan has to:
- extract the work context from the permit;
- choose or draft a monitoring flow;
- freeze a proposal with its revision and checksum;
- wait for a human to approve it;
- commit the task to the domain services;
- hand the task to the monitoring runtime.
The Agent Harness is the layer that carries that work without turning the model into the system of record.
The Agent is not the model
People sometimes use Agent and model interchangeably. For Lingan they are separate. The model reads the goal and decides the next step. The Agent is the model plus everything that makes the decision safe and reviewable.
That surrounding part is the harness. It assembles context, exposes a small set of tools, enforces approval, persists state, and recovers after interruption. The domain services underneath still own permissions, revisions, valid states, and the formal business record.
You can see why this matters by placing the same model in two different harnesses. In a coding harness, the model edits files in a workspace and the environment can throw the changes away. In Lingan, a write is a business action: it changes a Flow, a Task, or a running monitor. The harness therefore has to be stricter, not smarter.
Tools should describe outcomes, not endpoints
The quick way to give a model control is to mirror the backend. That produces tools like:
create_package add_rule add_action publish_package
A traditional frontend can call these in order because the page already knows the workflow. A model that has to guess that order is now carrying state between calls: which package, which rule, which step failed, and what to roll back.
Lingan prefers outcome-shaped tools. The model writes one complete, typed specification and makes a single call:
apply_flow_draft(spec)
The server validates the specification, checks permissions and revision, and saves it as one transaction. A failure returns a structured diagnostic and writes nothing. Publishing is a separate boundary:
publish_monitoring_flow(draft)
The model is not asked to re-create the database steps. It is asked to describe a result a person can review.
The governed path from document to monitoring
Take the hot work permit again.
The Agent first turns the document into a Work Context: permit number, area, equipment, valid window, and the controls that must stay true. Every field points back to evidence. If the area is missing, the Agent asks one question instead of guessing.
Next it finds a published Flow that covers the permit. If none fits, it drafts one. The draft is a candidate, not a running rule.
Then it prepares a Task proposal. Work Context, Flow Release, devices, and sampling are frozen into a revision and checksum, and the user sees the diff and the effect before anything starts.
Only after approval does the domain service create the Task and hand it to the Monitoring Runtime. The Runtime, not the model, tracks whether each control is met, deviated, unknown, or recovered over time.
Where the Agent stops and people decide
Reading, drafting, and previewing can run automatically. Actions that change the real world stay with authorized people: publish a Flow, start a Task, or change its lifecycle. The harness pauses at those boundaries and shows the business effect, not the internal function name.
Approval is not a reminder written in the prompt. It is a persisted step in the run. After approval, the server checks again: permit validity, Flow state, device access, and duplicate tasks. Only then does the write happen.
The harness remembers where it left off
Long work should not depend on one long request. When media analysis or document generation runs in the background, the run enters a waiting state and resumes automatically when the result arrives. The user does not ask is it done yet. If the process restarts, a waiting or approved step continues from persisted state instead of being replayed.
Where the harness does not reach
The Agent Harness does not make safety decisions and does not replace the Monitoring Runtime. It prepares work and hands it to deterministic systems. It also should not own every interaction: checking a list, pausing a selected task, or editing one clear field is usually better as a button than a conversation.
A coding agent can call a tool, but it is an executor inside a workspace. Lingan's Agent Harness is the product control plane that turns that work into an approved, recoverable business action.
See the governed path
See how one Agent turns a permit into monitoring, or ask us for a private walkthrough on a single high-risk work scenario.