Execution Model
Developer Reference
This page covers internal implementation details. It is not included in the User Guide.
The Platform Framework routes every request through a deterministic sequence of phases. Three execution flows. Three agent formulas. All stateless.
Three execution flows
| Flow | Trigger | Output |
|---|---|---|
| Standard | Single-domain prompt | Finding, Report, Triage — one skill, one LLM reasoning pass |
| Broad | Multi-domain or estate-wide question | Synthesised multi-domain report — parallel skill execution |
| Playbook | Write-capable operation or explicit trigger | Bundle → Run → Evidence — human approval always required |
Phase routing
Every request enters the Gateway and is classified through a deterministic sequence of phases:
Target assignment at Phase 1:
| Target code | Routes to | When |
|---|---|---|
H | Analysis Agent | Questions, analysis requests, read-only intent |
P | Playbook Agent | Write operations, remediation triggers |
R | Autoresolver | Automated resolution rules (no LLM call) |
The three agent formulas
Each flow maps to a different formula. The formula is deterministic — given the same inputs, the same phases execute in the same order.
Formula 1 — Standard (single domain)
Formula 2 — Broad (multi-domain)
Input: "Are any of my overprovisioned instances also security risks?"
Phase 1: classify → target = H, mode = broad
Phase 2: resolve skills → [finops.idle_detection, security.detect_public_ingress]
Phase 3: assemble combined context for both skills (parallel CE calls)
Phase 4: Analysis Agent executes both skill tool plans in parallel
Synthesises joint response correlating cost + security signals
Phase 5: UI Agent renders synthesised multi-domain report
Output: streamed cross-domain analysis with correlated findingsFormula 3 — Playbook
Stateless guarantee
The Platform Framework has no session state. Each request is self-contained:
- All conversation history is sent by the client in the
promptfield - All estate context is assembled client-side and sent in the
contextfield - Backend agents retain nothing between requests
- Scaling out backend agents requires zero session synchronisation
State lives in two places:
- Client (Tauri app): EstateView, conversation history, artifacts, evidence — in local databases
- Context Engine (server): registered skills, agents, tools, guardrails, templates, domain knowledge — in collections
Next steps
- Context Engine — Server-side knowledge resolution
- Context Manager — Client-side context assembly
- Platform Overview — The formula model