SMELT

Architecture

This page describes how the SMELT engine works under the hood. It is background reading - none of it is required to use SMELT Studio, which runs all of this for you as a hosted product.

When a workflow runs, blocks are dispatched through these layers - from the Wire API gateway through NATS to the agent workers and back.

System diagram

API Gateway

Validates requests and starts trace tracking

Message Bus

Durable delivery with replay for debugging

Orchestrator

Routes tasks - simple go direct, complex get decomposed

Five AI Agents

Planner, Research, Reasoning, Action, Validator

Memory

Working context, run history, semantic search

High-Speed Router

Message fan-out for parallel agent execution

Observability

Every agent call traced with model, latency, credits

Scroll to explore the architecture

Layer summary

  • Ingress - FastAPI: validates requests, stamps trace IDs, publishes to NATS (e.g. tasks.new). Rate limiting and JWT/API key authentication at the edge. No business logic.
  • Event bus - NATS JetStream: durable at-least-once delivery, consumer groups, replay for debugging.
  • Orchestrator - Python asyncio: consumes messages, runs a Pydantic state machine (TaskStatus), dispatches WorkItem, collects WorkResult. Supports multi-step chains and retry logic. No LangGraph dependency.
  • Worker agents: nine run. Five carry a model: PlannerAgent (goal decomposition into a sequenced sub-task DAG with dependencies), ResearchAgent (tenant-scoped pgvector retrieval, then synthesis over what it retrieved), ReasoningAgent (chain-of-thought with self-consistency voting and critique loop), ActionAgent (httpx tool executor with SSRF rejection and a PendingApproval human-in-the-loop gate), and ValidatorAgent (output quality assurance with rubric evaluation and critique loop). Four more carry none: ContentSafetyAgent, and the knowledge workers RetrieveAgent, IngestAgent and PurgeAgent. Workflow steps communicate over the bus; sub-agent delegation runs in-process inside the supervising agent’s worker and is recorded on the same run trace.
  • Memory: Redis (working / TTL), Postgres (episodic run history), pgvector (semantic retrieval with deduplication). Treating these as one database is an explicit anti-pattern.
  • Rust router: NATS and tonic gRPC for hot-path fan-out. Python calls Rust where throughput matters.
  • Observability: OpenTelemetry spans per LLM call (model, tokens, latency, credits) with structlog binding trace_id, agent_id, task_id. Jaeger for trace visualisation.
  • SMELT Studio: hosted workflow platform with visual builder, real-time execution monitoring, task timeline, and trace views.
  • Deployment: SMELT runs on Azure Container Apps. A deploy rolls a new revision without dropping traffic. The API layer runs several replicas; the agent workers run a fixed pool, so heavy fan-out queues rather than adding workers.

Technology stack

The stack SMELT runs on:

  • AI models
    Claude, GPT Series, Mistral, Llama
    Use our managed AI or bring your own OpenAI or Anthropic key
  • Workflow engine
    Python + Rust
    Python for agents, Rust for routing
  • Agent contracts
    Pydantic v2 (strict mode)
    Every input and output validated, no silent failures
  • Message bus
    NATS JetStream
    Durable delivery with replay for debugging
  • Memory
    Redis + Postgres + pgvector
    Working context, run history and semantic search
  • Integrations
    OAuth and API key
    Connect an account once and reuse it across workflows
  • Execution
    SSE real-time streaming
    Block-by-block streaming with live credits and duration
  • Observability
    OpenTelemetry
    Every agent call traced: model, latency, credits
  • Infrastructure
    Azure (managed)
    Managed containers, zero-downtime revision deploys

Start in SMELT Studio or read Getting Started.