The edge problem is not only inference
Edge AI is framed as a deployment problem. Put a smaller model near the sensor. Cut latency. Stop sending every event to a central cloud. Keep working when the network is slow, expensive or gone.
Those are real requirements. They are not the whole architecture.
An agent at the edge also needs context. It needs to know which assets, products, locations, contracts, procedures, permissions and outcomes matter for its task. It needs to write down what it observed or proposed. It needs to tell tentative local work from shared state. It needs validation before a change reaches other systems. It needs provenance, because an autonomous action without a trace is not an operational system. It is a liability.
So the edge question is not only "where does the model run?" It is also "where does the agent get governed knowledge, and where can it propose change?"
Legra does not need to be the agent runtime. It does not replace the model, the orchestration framework, the control loop or the local application. The stronger pattern is simpler: bring your own agent, connect it to a nearby Legra node, and let Legra carry the knowledge and the logistics around the work.
Bring your own agent
Different teams use different agents: editor agents, enterprise assistants, local models, cloud models behind controlled tool calls, domain workers written in ordinary code. That diversity is a reason to keep Legra out of the runtime business.
The integration surface stays narrow. An agent connects to a node through a
tool server, and the legra command line is also that server:
the agent uses the same commands as a person, as tools. What matters is the
boundary the tools enforce. The agent does not get the whole graph. It gets:
- scoped context for its workspace, use case and persona;
- the stories permitted in that context;
- a local branch where proposed changes are committed;
- validation feedback from declared shapes, policies and tests;
- provenance on every proposed change;
- a promotion path from local work into shared history.
At the edge that division pays. The local node sits close to the work. It serves cached context, records local branch history and synchronizes meaningful changes when connectivity allows. The agent does not depend on the central cloud as the only place knowledge exists.
Local context is not local memory
Many agent systems talk about memory: a vector store, a transcript, a scratchpad, a pile of retrieved documents. Useful, and weak as context for operational work.
Operational context is structured. An agent inspecting a production anomaly, a supplier substitution or a field maintenance issue needs to know which part of the business it acts in, which persona it acts as, which story it may perform, which outcome defines success and which rules apply.
At the edge this matters more. The agent may not reach the whole enterprise graph at all times. It may hold only the subgraph for one site, machine, vessel, aircraft or field team. That is not a defect. It is the point of logistics: move the right knowledge to the right node, keep the history verifiable, and stop pretending every decision needs a round trip to a central database. On Legra, copies live where the owner says.
The write boundary matters most
Read-only agents are the easy part. Give the model context, ask a question, return an answer. It can still go wrong, but the blast radius is small.
Agents get interesting when they propose change: record a maintenance observation, classify an event, flag a policy exception, propose a substitution, attach evidence to an outcome, prepare a change request. None of that lands in production. It lands on a branch.
The branch is the write boundary. It lets the agent work locally without turning every proposal into shared truth. It records what the agent did. It lets validation run while the work is isolated. It lets a reviewer inspect the diff. It lets automation promote clean changes through the same merge path that people and pipelines use.
The edge-agent pattern, in order:
- Bind the session to a workspace, use case, persona and story.
- Read local context from the nearest node.
- Commit proposed changes to a local staging branch.
- Validate the branch against declared rules.
- Iterate locally while warnings remain.
- Synchronize and merge accepted changes when the workflow allows.
The agent may be sophisticated or simple, local or remote. Safety does not come from trusting it. It comes from keeping context, permissions, writes, validation and promotion explicit.
Offline is not a switch
Edge systems are rarely simply online or offline. Connectivity is available but expensive, or intermittent, or fit for small semantic deltas but not for telemetry streams, or fit for synchronization but not for a control loop.
Branches and replication give architects a vocabulary for that reality. A local node keeps working with the state it has. A branch records observations and proposals while disconnected. When connectivity returns, durable branch history synchronizes under the workspace's policy. Nothing ships a whole database snapshot to say what changed. The unit is the change and the history around it.
The limits matter as much as the claims. Legra is not a telemetry broker. It does not replace real-time control software. It does not belong inside a safety loop that needs deterministic millisecond behavior. It is the knowledge and logistics layer around those systems: a place for local agents to get context, propose changes, keep evidence and rejoin shared history without pretending the network was perfect.
What the agent should see
The cleanest integration is a tool surface shaped by the use case, not a giant graph endpoint and a prompt that says "be careful." The agent sees enough to do the task and not enough to invent a new operating model. If it needs more context, that request is itself a governed tool call. If it wants to write, it writes to the branch.
The claim
Legra is not an edge AI engine. Edge and local agents need governed knowledge nearby, and Legra provides it through logistics primitives: branches, commits, validation, diff, merge, signed history, replication, encryption and graph-native context.
That fits how agent ecosystems evolve. The agent layer keeps changing. Model providers, editors, assistants, local runtimes and orchestration frameworks compete, and an enterprise should not tie its operational knowledge to one of them. The knowledge layer has to be stable, local, auditable and governed.
Bring your own agent. Connect it to the nearest node. Let it act through named stories, as a declared persona, on a local branch, with validation and provenance around every proposed change.
That is the logistics edge AI has been missing.
Try it in Legra
To connect an existing AI client, follow the MCP setup guide. Check its workspace selection and approval settings before allowing tools to run.