One runtime. Many agents. Any model.

System Engine

Every agent needs the same plumbing underneath it — project state, tool access, model connections, memory. Instead of every agent quietly reinventing that plumbing on its own, H-STAT centralizes it in one shared System Engine. The Engine starts the shared resources once, keeps track of what's actually happening across the whole system, and runs every agent's operation cycle. One engine, many agents, nothing duplicated.

Agent

An Agent isn't a model. It's a stateful worker that advances one task, goal, or workflow — and it can run at the same time as every other agent in the system, each on its own isolated slice of work, with no need to watch what the others are doing.

System Engine
  |-- Architecture Agent  --> working
  |-- Coding Agent        --> working
  |-- Test Agent          --> working
  `-- Documentation Agent --> working

  all four run concurrently, each unaware of the others

Four agents, four different jobs, running in parallel — the System Engine is the only one that needs to know all four exist.

Deliverables

Each agent hands back a Deliverable — a structured record of what it did, what it touched, and what state it started from. The System Engine checks every Deliverable against current state and against every other Deliverable before anything is accepted.

Say the Architecture Agent ships a schema migration while the Coding Agent, working from the old schema, ships code that assumes it. Neither agent watched the other. The System Engine sees both Deliverables, spots the conflict, and sends the Coding Agent back to retry against the new schema — automatically, not by an engineer noticing after the fact.

Workflows

Underneath every Agent is a simple workflow: check for input, decide what to do, do the work, verify it, report back. H-STAT breaks that into named states — waiting, using a Telescope, rendering the work, verifying it, rolling it back if it failed — so an agent's progress is always inspectable and resumable, never a black box mid-task.

Telescopes

Anything an Agent does that actually touches a model runs through a Telescope, not the Agent itself. A Telescope owns the prompt, the retrieval, the model connection, and the validation — completely separately from the Agent's own state. That separation means one Agent action can fan out to several Telescopes at once and pick a winner by rule, not by guesswork:

CodingTelescopes.execute_many(task, count=3)

  Telescope A --> candidate A --+
  Telescope B --> candidate B --+--> rule-selected winner --> Agent
  Telescope C --> candidate C --+

Three different model configurations run on the same task; because the Agent has many Telescopes, it is able to choose the winner based on business rules defined for the task. This allows the agent to orchestrate tasks against many models and escalate them as needed. Telescopes can contain all the logic for specialized tasks like triggering the loading of a model with XLA Studio, loading low rank adapters, and formatting requests and responses with filters so that the limits of specific models can be constrained at this Telescope interface.

LLM Model

At the bottom of every Telescope sits the actual model — one model, several models, a local one, a hosted one, whatever the task needs. Because the model lives inside the Telescope and never inside the Agent, changing providers, hardware, or model versions is a Telescope-level change. The Agent, its workflow, and everything built on top of it stay exactly the same.