An action the agent decides to take after reasoning about user input. The orchestrator parses LLM output into one of these actions.

A collaborative group where agents communicate via messages

Unique identity for an agent in a multi-agent system

Manages agent lifecycle with hooks and state tracking

A message passed between agents

Actions that can be audited

An entry in the audit log

Mutable circuit breaker state tracker

Circuit breaker configuration

Circuit breaker state

Result of a context compaction operation

Strategy for compacting context when it exceeds budget

One incremental piece of a streamed completion. A provider that supports streaming emits a sequence of these as the model generates: non-terminal chunks carry a text `Delta`, and the terminal chunk reports how generation finished plus token usage when the backend provides it.

Configuration for an LLM completion request

The result of an LLM completion

Result of a composed tool execution

Result of a consolidation pass

Strategy for consolidating memories

A declarative constitution governing agent behavior

Result of constitution evaluation

A rule in a declarative constitution that governs agent behavior

A single rule violation

Generic content metadata — describes what a tool/agent produces. The framework carries this tag without interpreting the content itself; consumers decide how to handle each content type.

Advanced context management beyond simple windowing

A conversation is a sequence of messages

A single persisted conversation message in a transport-neutral shape (decoupled from the runtime's storage record so this layer stays dependency-light).

One conversation-store write. Mirrors the store's mutating operations so a consumer can route each to whatever transcript store it chooses.

One process step (a tool call or sub-agent delegation) of an assistant turn, in a transport-neutral shape so the conversation event stream carries no storage-layer types.

Cost model for LLM provider pricing

Default factory that creates standard Orchestrator instances. Replace via DI to use a custom subclass of OrchestratorBase.

Dynamic tool discovery and pruning for context-window efficiency

An episode represents a discrete event in the agent's experience

Query for retrieving episodes

Complete ETCLOVG harness configuration wiring all seven layers together

The ETCLOVG Harness — integrates all seven layers into a unified execution pipeline

Result of an ETCLOVG harness execution

Composable event bus helpers.

Identity carried by every emitted event. The producer fills these in and never decides where the data lands — routing/persistence is entirely the consumer's choice, so a new storage strategy (per session, per category, per workspace, ...) needs no producer change.

Represents the execution context passed to an agent during its run

Orchestrates reverting tool executions in reverse order

Aggregated metrics for an agent execution

A record of a single tool execution (immutable, for journaling)

Captures a complete execution trace for offline analysis

Fallback strategy when primary execution fails

User feedback attached to a turn. The signal that drives adjustments.

Shared JSON options for feedback artifacts. The F# converter handles options, records, discriminated unions, and maps so everything round-trips cleanly.

Whether the user was satisfied with a turn.

Where a feedback signal originated. Explicit feedback is an intentional good/bad rating; conversation feedback is inferred heuristically from the chat history; memory feedback is surfaced by the memory system. The source is stored on each `Feedback` in its `Metadata` (see the `FeedbackSource` module) so the cross-session aggregator can weigh and explain its suggestions without breaking existing literals.

A node in the knowledge graph with typed properties

Query for traversing the knowledge graph

A relationship between two entities in the knowledge graph

Result of a graph traversal

Unified error type for the ETCLOVG harness, covering all failure modes

Helpers for constructing IHarnessServices values.

Abstract interface for an agent. Agents process user input and can communicate with other agents via messages. Agents are stateless per call: callers thread prior conversation into the input, and continuity is owned by the store/event path.

Interface for audit logging

Interface for generating text embeddings

Interface for episodic memory — stores sequences of experiences

The single dispatch service producers publish to. Fans each event out to all subscribed consumers; producers hold only this — never a concrete storage type.

A subscriber that receives every published event and persists/forwards it.

Interface for execution environment providers

Journal that tracks tool executions for revert/audit support. Framework provides the flow; consumers extend with persistence if needed.

Persists user feedback entries.

Interface for graph-based memory (knowledge graph)

Pluggable observability + governance services that a host (Orleans silo, ASP.NET app, test fixture, ...) injects into the harness. Each capability is optional so a host can supply only what it needs; `None` means that capability is disabled. This is the seam that lets callers choose in-memory (testing) vs persistent (production) backends without the harness/runtime knowing the concrete type.

Interface for automated quality judgement

Hook that can intercept lifecycle transitions

Abstract interface for LLM providers. Implementations wrap specific backends (Ollama, OpenAI, Anthropic, etc.)

Interface for an MCP client connection to a single server

Registry of multiple MCP server connections

Interface for memory consolidation (background process)

Interface for persisting and retrieving agent memories

Interface for metrics collection

Factory interface for creating orchestrator instances via DI. Register a custom implementation to control how orchestrators are built from workspace definitions.

Pre-flight readiness checks before agent execution

Semantic memory store that uses embeddings for similarity-based retrieval

Optional capability a provider implements when it can return the completion incrementally (token by token) instead of buffering the whole response. `onChunk` is invoked on the calling task for each delta as it arrives; the returned `CompletionResult` is the fully aggregated completion (identical in shape to `CompleteAsync`), so a caller that streams to a UI and also needs the final text requires no extra bookkeeping.

Interface for tiered memory management

Interface for dynamic tool discovery, ranking, and context-window pruning

Middleware that wraps tool execution (pre/post processing)

Protocol for tool discovery and invocation (MCP-inspired)

Interface for trace collection

Stores execution traces for regression comparison

Persists completed turn records so feedback can be analysed against them later.

Interface for task-scoped working memory (scratchpad)

Result of automated judgement on an execution

Verdict from an automated judge

Events emitted during lifecycle transitions

Executes a multi-stage lifecycle pipeline with validation and retry

Full lifecycle pipeline result

Agent lifecycle states following a state-machine model

The specific limit that was exceeded

LLM-based judge that evaluates execution traces

Helpers for invoking providers.

Default execution environment that runs agents in-process with resource tracking

Severity level for agent log entries

MCP capability flags

State of an MCP connection

Registry managing multiple MCP connections

MCP resource (file, data, etc. exposed by server)

MCP server info as advertised during initialization

MCP tool definition as received from a server

MCP transport type

Memory consolidation operating on IMemoryStore

A single memory entry stored by an agent

Policy for memory promotion/demotion between tiers

Three-tier memory model: Short-term (active context), Mid-term (session), Long-term (persistent)

A single message in a conversation

A single metrics data point

Domain events the system dispatches. Each carries an EventScope plus its payload. Consumers subscribe to the bus and decide how/where to persist, so adding a storage strategy never requires touching the producers. (Grows per phase: feedback, then observability, then conversations.)

Builds the per-turn IHarnessServices bundle handed to the agent harness. Each session's observability lives in its own backing bundle (e.g. sessions//observability/), built lazily by `backingFactory` and memoised; the returned bundle tees every write to the bus while reads delegate to that backing store. Where the data lands is the store-level swap point (the backing factory), so producers never change.

One fine-grained observability write produced by the agent harness during a turn. These mirror the sink interfaces (ITracer / IMetricsCollector / IExecutionJournal / ITraceStore / IAuditLog) so a consumer can route each to whatever store it chooses.

Default orchestrator implementation using the base class with no overrides.

The fundamental orchestrator agent. Accepts user input, uses an LLM to decide which tool or sub-agent to invoke, executes the action, feeds results back, and produces a final response. Subclass and override virtual members to customize behavior.

Configuration for the Orchestrator

Memory management configuration for the orchestrator

Output format the agent should produce. Controls the formatting instruction appended to the system prompt.

No-op lifecycle hook for default behavior

A specific permission grant for a capability

The outcome of evaluating an access request.

Canonical, structured refusal handed back to the model whenever a resource access is denied. Centralizing it here keeps every enforcement point (a tool's own declared permissions, the runtime context, the server guard) emitting the same machine-readable shape — `{ error, kind, resource, message, hint? }` — so agents can relay denials consistently. The optional hint lets the server add UI-specific guidance.

A process-wide hook the server registers so the runtime layer (which cannot reference the server) can resolve permission requests against the real decision logic — settings, persisted grants, and the interactive prompt. When unset, access is allowed (no permission system present, e.g. in tests).

Permission level for a specific capability

The permission model governing an agent's allowed actions

The result of resolving a permission request: the decision plus whether the user asked to remember the grant for the rest of the session (so the session can record it in its own state rather than re-prompting).

A single allow/deny rule the user granted.

Permission scope categories

A pipeline processes input through a sequence of agents

Defines a stage in a lifecycle pipeline (issue-to-deployment style)

A governance policy that can be enforced at runtime

Context passed to policy evaluation

How a policy violation is handled

Runtime policy engine that evaluates all registered policies

Result of policy engine evaluation

One conversation-store write. Mirrors the store's mutating operations so a consumer can route each to whatever transcript store it chooses.

Functions for working with structured prompts

A structured prompt definition following prompt engineering best practices

A single few-shot example demonstrating expected input/output behavior. Used within a Prompt to guide the LLM's responses.

An IHarnessServices bundle whose every write is teed to the bus as an ObservabilityCaptured event while reads delegate to the wrapped backing bundle. The grain hands this to the agent harness, so the full observability stream flows through the bus without the producer ever deciding where it is stored.

Readiness check result

Categories of regression

A single regression item

Regression detection: compare current trace against baseline

Resilience module for executing with retry, circuit breaker, and fallback

Resilience configuration combining retry, circuit breaker, and fallback

A sensitive action a tool or agent wants to perform, together with the specific resource it targets. The permission system decides whether to allow it. This is the resource-level companion to the capability-level `Permission` model: where `Permission` asks "may this agent use tool X?", `ResourceAccess` asks "may this run touch THIS path or THIS url?".

The class of resource a rule matches.

Resource budget constraints for agent execution

Pure evaluation of resource-access requests against a set of granted rules. No IO — the persistence and enforcement layers live in the server; this module is the testable core.

Tracks current resource consumption against limits

Retry policy for resilient execution (shared across Lifecycle and Observability layers)

Context provided to a tool's Revert function so it can undo its effects

Represents a message role in a conversation

Router dispatches input to the most appropriate agent

Strategy for selecting which agent handles a request

Categories of constitutional rules

How broadly a granted rule applies.

Configuration for the execution sandbox

Isolation level for agent execution sandbox

A memory entry with an embedding vector for semantic retrieval

Types describing background work a tool or orchestrator can launch. There is no ambient state here: the session/turn identity a unit of work belongs to is carried explicitly on the `ToolContext` the runtime threads into every tool and orchestrator.

A single span in a distributed trace

An event within a span

A span within a trace (represents a unit of work)

Span status

Result of a single pipeline stage execution

Stdio-based MCP client implementation

A single sub-agent delegation captured during a turn.

Configuration for conversation summarization

Task grounding: validates that the agent understands what it needs to do

Termination condition for a collaborative group conversation

Configuration for tiered memory management

A memory item with tier classification

A tool that an agent can invoke to perform actions or retrieve information. Supports optional capabilities: content-type declaration, verify, and revert.

Tool availability status

A single tool invocation captured during a turn.

Executes tool compositions against an IToolProtocol

A composed tool that chains, parallelizes, or conditionally routes between tools

Helpers for the tool execution context.

Runtime context handed to a tool's Execute (and to the orchestrator) so it can request approval for sensitive resource access dynamically — based on its own input or intermediate results — locate the session's file folder, and launch background work. The runtime builds one per session/turn and threads it explicitly; library and test code can use `ToolContext.allowAll`.

Cost category hint for tool selection optimization

Configuration for tool discovery and pruning

Example of tool usage for documentation and few-shot prompting

Result of a tool invocation with metadata

Describes a single parameter a tool accepts in its JSON input object.

Routes tool invocations through middleware and protocol

Helpers for building tool provenance values.

Identifies where a tool originated, so feedback-driven adjustments can target the correct source (a JSON file to re-version, or a compiled assembly to patch).

Routes tool requests to the appropriate tool based on strategy

Rich schema definition for a tool, extending the basic Tool type

Tool selection result with reasoning

Strategy for selecting which tool to use

A step in a tool composition

Tool usage statistics for ranking/pruning

Actions that can appear in a trace

A unique trace identifier for correlating events across agent calls

A single step in an execution trace

A complete record of one orchestration turn: the user prompt, the agent and tools that ran, and the final answer. This is the unit feedback is attached to.

An `IEventConsumer` that accumulates the progress signals of a single turn into a structured `TurnRecord`. Subscribe it to the `IEventBus` for the duration of one turn (matched by `scope.ActionId = turnId`), then call `Snapshot`. The orchestrator publishes `ToolInvoked`/`ToolCompleted` (and `SubAgentInvoked`/`SubAgentCompleted`) pairs sequentially, so we match each result to the earliest still-unmatched invocation of the same name (FIFO).

One step of the process an agent ran during a turn, captured in the order it happened (a tool invocation or a sub-agent delegation). Lets a frontend show the whole process — reasoning trail and tool calls — not just the final answer.

Captures and manages execution traces for verification

Helpers for version-qualified references of the form "name@version". Used to look up a specific version of a tool or agent while remaining backward compatible with plain, unversioned "name" references.

Strategy for managing conversation history length

Configuration for working memory

A scratchpad item in working memory with priority/attention weight