Platform Overview

The Escher Platform Framework is a stateless execution engine built on a single formula, not a collection of autonomous agents.

Why not 100 autonomous agents?

The natural instinct when building an agentic platform is one agent per domain: a FinOps agent, a SecOps agent, a Compliance agent, and so on. For 7 domains this seems manageable. But the problems that arise are hard to undo:

Maintenance explosion: Each agent is a separate deployment unit, a separate prompt context, a separate update surface. Consistency of behaviour across agents becomes increasingly difficult to enforce.

Fragmented reasoning: A prompt like "My EC2 is slow and has a security risk" gets split across agents that each see only a slice. No single agent has enough context to reason holistically. Cross-domain correlation is lost.

Hallucination risk: Each isolated agent reasons from its own narrow context. Without grounding, agents fill gaps with invented answers.

Escher's answer: One formula. 100+ registered skills. The formula executes for every skill. The agents in Escher are not autonomous reasoners — they are stateless executors of a deterministic formula whose inputs are fully governed and traceable.

The Formula

Every domain in Escher has the same shape:

Any domain =
  Skills        → what it knows how to do
  Knowledge     → what it understands about the world
  Output format → how it communicates results

Escher makes each part of that structure explicit, registered, and executable:

Agent(x, d, t, e) =
  Skill(x)              → what to execute
  ContextBuilder(x)     → what data to fetch from the estate
  Estate(e)             → the live estate assembled by Context Manager
  Tool(CB(x))           → the tools that fetch that data
  Guardrail(x→d)        → the constraints that govern execution
  Template(x→d)         → how to render the output
  DomainLens(d)         → expert domain knowledge         [advanced tier]
  ExpertGraph(d)        → control relationships            [advanced tier]
  Artifact(x, t)        → what to persist
  Evidence(runtime, t)  → the audit trail

Where:

x = the resolved Skill
d = the domain (security, finops, compliance, ...)
t = the current session/tenant context
e = the current EstateView

Every variable is registered in the Context Engine before runtime. Nothing is invented at execution time.

The LLM is not the agent. The LLM is the reasoning engine inside the formula. The agent is the formula itself — a pure function over registered, governed, observable inputs.

What this means in practice

Traditional agent model	Escher formula model
Autonomous, opaque	Autonomous, transparent
Owns its own state	Stateless — state lives in Context Manager
Decides its own tools at runtime	Tools declared in manifest, selected by platform
Hard to audit	Every variable is registered and traceable
Hard to govern	Guardrails are first-class formula inputs
Adding a domain = adding a new agent	Adding a domain = registering new values into the same structure
100 agents = 100 black boxes	100 skills = same formula, different inputs

The intelligence is not in the agent. The intelligence is in the assets the formula resolves.

Thin backend, stateful frontend

The most important operational principle:

Frontend (Tauri desktop app):
  Local RAG (estate)   → your cloud estate data, never leaves the machine
  Serial DB            → full conversation history, session state, artifacts, evidence

Backend (stateless agents):
  No user state        → every request is self-contained
  No credentials       → credentials never leave the client
  No estate data       → context is assembled client-side and sent per request

The backend agents receive fully-assembled context per request. They reason, produce output, and return it. They retain nothing between calls.

This architecture makes Escher safe to deploy for enterprise customers: sensitive estate data, credentials, and conversation history live on the customer's machine, not in Escher's infrastructure.

Components

Component	Role	Location
Desktop App (Tauri)	UI, credential management, local estate store, skill execution	Client
Tauri Plugins (Rust)	Estate scanning, vault, scheduler, flow logger, execution engine	Client (embedded)
Context Manager	Assembles client-side context (estate RAG + conversation history) per request	Client
Gateway	Routes incoming prompts through classification phases to the correct agent	Server
Domain Agents (Go/Java)	Stateless executors of the formula — Analysis, Playbook, Autoresolver, KB, Log Analysis	Server
Context Engine	Server-side knowledge store: skills, agents, tools, guardrails, templates, domain knowledge	Server
Asset Store	Persistence layer for the Context Engine (SurrealDB-backed)	Server
ADK	Author and register agent packages (agent.yaml → Context Engine collections)	Developer tool

Next steps

Execution Model — The three execution flows and gateway phase routing
Context Engine — The server-side knowledge API
Context Manager — How client-side context is assembled
agent.yaml Reference — The single source of truth for domain teams

Platform Overview ​

Why not 100 autonomous agents? ​

The Formula ​

What this means in practice ​

Thin backend, stateful frontend ​

Components ​