Penton Systems / Experiences / 06
06 Experience · Applied AI systemsThe Intelligence Engine
A working agent runtime, running in your browser. It plans a mission, calls real tools, spreads computation across your processor cores, watches live signals, and stops to ask a person before it acts.
No model.
No script.
This engine plans with explicit rules, not a language model. Every tool call below is real.
When it fetches space weather, it calls NOAA through our caching gateway. When it measures latency, it times real round trips from your browser to our Orlando web node. When it distributes work, it starts real Web Workers on your device and merges what they return. When it needs a decision, it waits for you, for as long as it takes. It never acts on a timeout.
What it does not do: hold a conversation, invent data, or claim results it did not compute. If a source fails, the step is marked unavailable and the report says so.
- Live
- Fetched or measured during your run, from the named source.
- Cached
- Real data older than its refresh window. Orbital elements refresh upstream every two hours.
- Simulation
- A real algorithm applied to hypothetical inputs you chose.
- Unavailable
- The source failed. Nothing is estimated to fill the gap.
Give it a mission
Pick a mission, adjust the inputs and watch the planner rebuild the task graph before anything runs. Press run, and every node you see is a real call.
| T+ s | Tool | Event | Detail | Data |
|---|
Findings
- Findings appear here when the assessment step runs.
The report is compiled at the end of the run.
Seven parts.
All inspectable.
The same structure we use when we build agent systems for real operations, reduced to what fits in a browser tab.
- 01
Planner
Mission rules are evaluated against your inputs. Each rule that fires adds steps and dependencies. Change an input and the graph changes before anything runs.
- 02
Tool registry
Every capability is a named tool with a declared source. The engine can call nothing that is not in the registry below.
- 03
Executor
Runs the task graph in dependency order, up to four steps at once. A failed step is recorded as unavailable and its dependents carry on without it.
- 04
Distributed workers
Heavy work is split into shards and handed to Web Workers on your device. Each worker reports progress and throughput; a reducer merges the results. Workers are terminated when the step ends.
- 05
Monitor
A loop that re-measures live signals on an interval and raises an alert when a threshold is crossed. Thresholds are yours to set.
- 06
Approval gate
Anything that changes state, or uses your processor heavily, waits for a person. Rejection is a first-class branch, not an error.
- 07
Audit log and report
Every call, result, alert and decision is timestamped. The report lists sources, data freshness, findings and the human decision, in plain text.
Tool registry
| Tool | What it does | Kind | Source |
|---|---|---|---|
| The registry is listed here when scripts are enabled. | |||
Orbital positions are SGP4 predictions from public elements (satellite.js), typically good to about a kilometre for low orbit with fresh elements. Space weather is NOAA SWPC real-time data, read through our server-side cache. Rebuild-risk figures are models on hypothetical inputs, not predictions for any specific array.
Evidence first.
People decide.
- 01
Evidence first
Every recommendation cites the data it came from, with its source and age.
- 02
Humans approve changes
Agents propose; people approve. Nothing destructive runs unattended, and a rejection is recorded, not retried.
- 03
Private by default
Models and tools can run on hardware you own, so sensitive data stays inside your network.
- 04
Bounded tools
An agent can only call what is registered, with declared inputs and outputs. That is what makes it auditable.
This page demonstrates how we structure agent systems. Client deployments are scoped individually and may use language models where they add value; when they do, the same planner, tool, approval and audit boundaries apply.