Teleodynamic Desktop App Architecture from a Local LLM Wrapper

Full report

On this page

Executive summary

Teleodynamic.com presents teleodynamic AI as a claim-bounded, static research and architectural lens for “constraint-maintaining intelligence,” not as proof of a deployed autonomous organism, product certification, agent runtime, AGI, or consciousness. Its primary ideas are that structures, parameters, and resource state should co-evolve under constraint; that useful structure must keep “paying for itself” through resource closure; that work should maintain constraints and constraints should channel future work; and that no-op is the correct action when evidence, budget, or safety is insufficient.

For a Windows WPF app, that means a “Teleodynamic app” should not simply be “a local chat UI wrapped around a model.” It should be a local control regime around a model runtime: a shell that tracks resources, goals, approvals, memory state, alternatives considered, and reasoned refusals; separates theory/metadata/memory/runtime into explicit lanes; and prefers bounded behavior over invisible autonomy. Teleodynamic’s own architecture page emphasizes a two-timescale design: a fast loop for ongoing adaptation within the current working structure, and a slow loop for discrete structural changes such as split, merge, add, retire, or no-op, gated by evidence and resource state.

Starting from a simple WPF + LLamaSharp + GGUF wrapper, the best near-term target is not “general autonomous agent.” It is a bounded operator in the Teleodynamic capability ladder: a system that keeps a visible resource trace, documents slow-loop decisions, enforces no-op under ambiguity, and escalates structural changes to human review. That aligns most closely with Teleodynamic’s L3 to L4 range, not its higher, multi-domain governance-aware interpretations.

The recommended architecture is a local-first desktop control plane built from: a WPF shell; a WebView2 onboarding/configuration wizard; an AgentController and GoalArbiter; a MemoryManager with a SQLite working store and .uai import/export package; a PromptAssembler; evaluation and safety gates; isolated worker processes for model runtimes; a local API and capability registry; a download/verify/storage subsystem; and a local telemetry/privacy guard that defaults to no outbound execution or phoning home. This direction also matches the uploaded LocalEndpoint desktop design note, which pushes actual model execution into the desktop client behind modular runtime hosts rather than the public discovery surface.

For model support, GGUF via LLamaSharp should remain the primary LLM path because LLamaSharp is explicitly built to run models locally on CPU and GPU and ships backend packages for CPU, CUDA, Metal, and Vulkan, while using GGUF as its model format. ONNX Runtime is the best secondary runtime for custom helper models and non-GGUF imports because it supports C# and interoperates with models from PyTorch, TensorFlow/Keras, TFLite, scikit-learn, and other ecosystems while exposing multiple execution providers, including DirectML on Windows. LiteRT is credible as a future pathway, but its overview highlights C++, Kotlin, Python, and Rust bindings rather than C#, so it is better treated as a later native adapter rather than a first-wave .NET integration target.

Security-wise, the biggest design mistake would be treating “local” as automatically safe. Teleodynamic’s own local-sandbox guidance explicitly says local execution does not eliminate safety risk and rejects blind tools, arbitrary code execution, credential validation, and private-network probing as default behaviors. That combines naturally with Windows isolation primitives such as AppContainer and Job Objects, and with a model-ingestion policy that prefers GGUF/ONNX and quarantines unsafe raw checkpoint formats. PyTorch warns that torch.load() uses Python unpickling under the hood and says never to load untrusted data; TensorFlow warns that models are code and that untrusted code requires care.

Teleodynamic in context

In this report’s context, teleodynamic should be defined narrowly and operationally: a local AI application in which temporary structures such as goals, routing state, memory edges, tools, and prompts are not accepted merely because they exist, but only when they continue to improve future work enough to justify their maintenance cost under bounded resources. Teleodynamic.com states this explicitly as “not a larger model” but “a different control regime,” where structure expands only when predictive gain repays structural cost and where resource state is part of the learner rather than an external stop rule.

The site’s core concepts page unpacks that into several engineering principles. First, constraint-maintaining intelligence means a structure should remain active only when it improves future work without hiding unsupported meaning, governance risk, or maintenance burden. Second, resource closure means a proposed structure must justify creation and maintenance costs across compute, review burden, governance risk, uncertainty, and memory pressure. Third, the Work-Constraint Cycle says work maintains constraints and constraints channel future work. Fourth, no-op dominance means refusal is not failure; it is the correct teleodynamic response when change adds more ambiguity, maintenance burden, or unsupported authority than benefit.

Teleodynamic.com also places unusually strong emphasis on epistemic firewalls and claim boundaries. It explicitly separates public theory, machine-readable JSON, evidence packets, UAIX schemas, and runtime systems into different lanes, and it repeatedly warns against turning static theory into execution authority, certification, or proof of autonomy. That matters for app design: a Teleodynamic desktop app should treat its own memory packages, LocalEndpoint-style discovery metadata, and UI wizard content as inputs to judgment, not automatic permission to act.

That same caution should shape capability claims. In Teleodynamic’s L0–L6 framework, a typical single-turn prompt wrapper is best understood as roughly L1/L2: it can organize temporary context and maybe use supervised tools, but it does not yet prove internal resource closure or durable slow-loop structural change. The first meaningful Teleodynamic target is L3, where bounded structural proposals, resource traces, documented split/merge/add/retire/no-op actions, and mandatory human review for promotions become visible. A mature desktop app grounded in one bounded domain can reasonably aim for L4 later, but it should avoid shipping language that implies higher-order autonomy without much stronger evidence.

One more principle is central: evaluation before promotion. Teleodynamic’s Evaluation Lab says outputs should expose metric families, review gates, and audit worksheets, and that failed gates should halt, downgrade, expose alternatives, or enforce no-op. Operational viability on the site includes latency, fallback rate, review pressure, resource retention, blocked actions, and trace auditability. For desktop engineering, that translates directly into a product requirement: any system that mutates memory, escalates background work, or widens tool use must carry an auditable reason, a budget trace, and a visible approval state.

Mapping Teleodynamic concepts to desktop components

A workable desktop mapping emerges when Teleodynamic’s abstract ideas are converted into explicit subsystems rather than hidden “agentic magic.” The key move is to treat the desktop app as a boundary-rich organism-like control plane around local runtimes, not as a monolithic executable.

This mapping synthesizes Teleodynamic’s memory strategy, Resource Economy, capability ladder, evaluation gates, local-sandbox rules, and LocalEndpoint boundary lens. The memory guidance explicitly distinguishes active intake from reviewed long memory, while the LocalEndpoint architecture page says endpoint discovery metadata, validation reports, and roadmap labels should make a boundary inspectable before any runtime action is widened.

A strong memory design naturally follows from that. Teleodynamic’s homepage says “short handoff here, long memory in AIWikis,” and describes active intake via UAIX file handoff buckets, plus longer-lived reviewed memory and promotion rules. For a desktop app, the cleanest interpretation is: keep ephemeral/active memory in a working store; keep reviewed semantic memory in a promoted store; and package export/import as a .uai archive that captures both machine-usable context and human-auditable provenance. The .uai format does not need to be mystical. It can simply be a project-specific container around a manifest, UTC-stamped audit records, episodic items, semantic facts, embeddings, and attachments, while clearly marking every item’s review state.

The sensor/actuator side should mirror LocalEndpoint’s discovery-and-validation philosophy. Teleodynamic’s LocalEndpoint lens says a local endpoint is the place where protocol expectations, permissions, metadata, and validation become local operational facts, and it warns that endpoint discovery or cataloging is not the same thing as execution permission or security assurance. That should map directly to a CapabilityRegistry in the desktop app: every tool, worker, file lane, and background task gets a manifest with declared capability, domain, budget, hazards, and approval requirements, and any missing or stale manifest makes the correct action no-op.

UI/UX should also be teleodynamic, not merely decorative. Teleodynamic’s trust-posture material emphasizes evidence-bounded trust, visible boundaries, repairability, and review before widening claims; the Evaluation Lab stresses auditability and human comprehension. In a desktop app, that implies a shell with plainly visible panels for goal state, model/runtime health, active memory, pending promotions, blocked actions, and audit traces, along with a human-approval workflow that makes it emotionally obvious when the system is thinking, waiting, blocked, degraded, or requesting escalation.

Architecture and integration plan

Assuming the current codebase is the simple baseline you described — a single-process WPF shell calling LLamaSharp directly against one GGUF model — the right evolution is not a rewrite into a giant framework. It is a progressive extraction of a control plane: first abstract the model runtime, then isolate it, then add memory, then add an agent controller and review gates, then add multi-runtime support, then add background slow loops. The uploaded LocalEndpoint desktop design note already points in the same direction: the public site remains discovery/metadata, while the desktop client becomes the execution environment through runtime-host abstractions and worker processes.

Architecture diagram

flowchart LR
    subgraph UX["Desktop UX"]
        UI["WPF Shell"]
        WZ["WebView2 Wizard"]
        AP["Approval & Audit Panels"]
    end

    subgraph Control["Teleodynamic Control Plane"]
        AC["Agent Controller"]
        GA["Goal Arbiter"]
        PA["Prompt Assembler"]
        EV["Evaluation & Safety Gates"]
        MM["Memory Manager"]
        UAI[".uai Package Import/Export"]
        RG["Runtime Registry"]
        PG["Privacy & Telemetry Guard"]
    end

    subgraph Data["Local State"]
        SQ["SQLite Working Store"]
        IDX["Embedding / Retrieval Index"]
        AU["Audit Log"]
        DS["Download Cache & Model Store"]
        MF["Capability Manifests"]
    end

    subgraph Runtime["Runtime Hosts"]
        MH["Model Host"]
        LH["LLamaSharp GGUF Host"]
        OH["ONNX Runtime Host"]
        WH["Worker Host Supervisor"]
    end

    subgraph Workers["Isolated Worker Processes"]
        LW["GGUF Inference Worker"]
        OW["ONNX Helper Worker"]
        TW["Tool / Background Task Worker"]
    end

    subgraph Boundary["Local Interfaces"]
        API["Local API"]
        LE["LocalEndpoint-style Discovery Layer"]
        DV["Download / Verify / Storage"]
    end

    UI --> AC
    UI --> AP
    WZ --> RG
    WZ --> DV
    AP --> AC

    AC --> GA
    AC --> PA
    AC --> EV
    AC --> MM
    AC --> RG

    MM --> SQ
    MM --> IDX
    MM --> AU
    MM --> UAI

    RG --> MF
    EV --> AU
    PG --> AU
    PG --> UI

    DV --> DS
    DV --> MF

    PA --> MH
    MH --> WH
    WH --> LH
    WH --> OH
    LH --> LW
    OH --> OW
    WH --> TW

    API <--> TW
    LE --> RG
    LE --> EV
    DS --> LH
    DS --> OH

This layout intentionally mirrors Teleodynamic’s two-timescale reference architecture and its insistence on explicit boundaries. The AgentController and GoalArbiter are the slow-loop governance surface; the runtime workers are the fast-loop execution surface; the MemoryManager, capability manifests, and evaluation guardrails make the action explainable; and the LocalEndpoint-style discovery layer remains a description and validation surface rather than merged execution authority.

Design option comparisons

This comparison follows from two facts: LLamaSharp depends on native backend libraries, and Windows Job Objects are explicitly designed to manage groups of processes as a unit, set limits, and terminate them together if required.

This recommendation fits Teleodynamic’s explicit split between active intake and reviewed long memory, and it uses Microsoft.Data.Sqlite’s lightweight ADO.NET provider as the core working store.

Named pipes are directly supported in .NET through NamedPipeServerStream/NamedPipeClientStream, while System.IO.Pipelines is designed to simplify high-performance streaming I/O. gRPC on .NET is explicitly documented as a high-performance RPC framework with streaming and strong contract generation.

Integration path from the simple wrapper

The migration path should be incremental.

First, extract a ModelHost abstraction from the existing LLamaSharp calls. That gives the current wrapper one seam without changing the user-facing UI. LLamaSharp is already a local runtime library with GGUF expectations and native backend packages, so it is the natural baseline implementation of that interface.

Second, move the LLamaSharp call path into a worker process supervised by the WPF shell. Because the backends are native and model footprints are large, isolating them buys reliability immediately: UI crashes and runtime crashes stop being the same event, and process limits become feasible through Job Objects.

Third, add a SQLite-backed MemoryManager plus .uai packaging. The active store should maintain conversation episodes, promoted semantic facts, approval events, tool manifests, download provenance, and full audit traces. The .uai package should export/import a bounded subset of that state with a manifest and hashes, so memory remains inspectable and portable without becoming an opaque blob.

Fourth, add a PromptAssembler that pulls together system policy, current goals, recent dialogue, semantic memory, episodic memory, capability manifests, and resource budgets. This is where the control regime becomes visible: prompts stop being “chat history plus user message” and become structured products of the app’s current viability state and approvals. That is the first genuinely teleodynamic move.

Fifth, add an AgentController and evaluation gates. Every background job, memory promotion, and tool call should pass an explicit gate layer derived from the site’s operational viability, human review, stability, evidence retrieval, and auditability concepts. The app should be able to say: “I could do X, but evidence is incomplete, so I stayed in no-op.”

Sixth, broaden runtime support. Keep GGUF/LLamaSharp as the main chat-completion path. Add ONNX Runtime for embedders, rerankers, classifiers, policy models, helper multimodal components, or custom converted models that benefit from Windows DirectML or other execution providers. ONNX Runtime’s documentation is especially strong for this hybrid position because it has C# support, broad framework interoperability, and execution-provider selection. A useful engineering caveat: ONNX Runtime’s quantization/optimization tooling documents a known inability to output optimized models larger than 2 GB, so giant decoder-LM conversion should not be the center of the MVP plan.

Seventh, add a download/verify/storage subsystem that behaves like a supply-chain boundary. Hugging Face’s download tooling allows constrained fetches through snapshot_download() with allow_patterns and ignore_patterns, its cache is keyed by ETag, and model cards carry machine-readable metadata such as license, datasets, and base model. That supports a very practical WPF wizard: fetch only the needed artifacts, record upstream ETag and local SHA-256, preserve model card provenance, and require explicit user confirmation for gated models that share account details with model authors.

Teleodynamic behavior design

A Teleodynamic desktop app should behave less like a conversational toy and more like a bounded local coordinator whose first duty is keeping its own boundaries, state, and costs intelligible.

Behavior loop

sequenceDiagram
    participant U as User
    participant AC as Agent Controller
    participant MM as Memory Manager
    participant PA as Prompt Assembler
    participant MH as Model Host
    participant EV as Evaluation Gates
    participant AP as Approval UI
    participant AU as Audit Log

    U->>AC: Submit goal or message
    AC->>MM: Retrieve recent episodes, semantic facts, approvals
    AC->>PA: Build bounded prompt with budget + capability context
    PA->>MH: Generate proposal
    MH-->>AC: Response + latency + token/resource metrics
    AC->>EV: Evaluate viability, evidence, safety, stability
    EV-->>AC: Pass / Caution / No-op / Needs approval
    alt Needs approval
        AC->>AP: Request human review
        AP-->>AC: Approve / Reject / Revise
    end
    AC->>MM: Commit episode, update goal state, maybe propose promotion
    AC->>AU: Record rationale, alternatives, outcome
    AC-->>U: Final answer, blocked action notice, or no-op explanation

This sequence is directly aligned with Teleodynamic’s insistence that work maintains constraints, constraints channel future work, and failed gates should halt, downgrade, expose alternatives, or enforce no-op. The point is not to dramatize “agency”; it is to make the control regime inspectable.

Continuous goal management

Goals should be first-class records, not just hidden prompt hints. Each goal needs a priority, bounded domain, expected payoff, approval class, and resource budget. The controller should maintain a goal stack plus a background queue, but only one or two “active goals” should influence prompt assembly at a time. When a goal becomes stale, too costly, contradictory, or insufficiently evidenced, the controller should explicitly emit Retire or No-op rather than silently carrying dead intent forever. That is exactly the kind of slow-loop structural action Teleodynamic names: split, merge, add, retire, or no-op.

The most important product behavior here is graceful refusal with context. Teleodynamic’s autonomy-washing guide specifically warns against confusing tool chaining, schema conformance, or memory continuity with genuine autonomy, and insists reviewers ask what resource trace supports a claim, what slow-loop action was documented, and what the no-op alternative was. In a desktop app, that becomes a UX rule: every blocked action should tell the user what evidence was missing, what resource or policy limit fired, and what narrower next step is still safe.

Local reinforcement signals

For an MVP, “reinforcement” should not mean on-device weight training. Teleodynamic.com explicitly keeps theory separate from live model training and runtime claims, and the right first implementation is controller-level reinforcement, not base-model fine-tuning. The app should collect local signals and feed them into goal ranking, memory promotion, retry policy, context assembly, and tool eligibility.

A good signal set is small and auditable: user approval or rejection; correction frequency; retrieval agreement; contradiction count; blocked-action count; latency; fallback rate; CPU/RAM pressure; and whether a third party could reconstruct how the output was produced. Those align tightly with Teleodynamic’s operational viability, review pressure, stability, and auditability metrics. Positive signals should strengthen a pattern’s future selection probability; negative signals should lower confidence, shorten retention, or force more human review.

Episodic memory, semantic memory, and compaction

The memory model should have three tiers.

The working episode tier stores raw interaction records, tool proposals, resource traces, approval events, and artifacts. This tier is cheap to write and easy to expire.

The semantic tier stores distilled facts, preferences, stable workflow patterns, and capability summaries only after they survive compaction and review. Promotion into this tier should require agreement between retrieval quality, stability, and auditability thresholds, plus human approval for sensitive items. That is how the Teleodynamic split between active intake and durable reviewed memory becomes real engineering instead of metaphor.

The portable .uai tier is the exchange/snapshot representation. A reasonable initial layout is:

project.uai/
  manifest.json
  episodes.ndjson
  semantic.sqlite
  approvals.ndjson
  artifacts/
  embeddings/
  audit/
  hashes.json

manifest.json should include schema version, creation time in UTC, model/runtime provenance, upstream ETags, local SHA-256 hashes, approval state summary, and package classification. Secrets should never be packed into this archive. That design is an implementation inference from Teleodynamic’s active-intake and reviewed-memory model, coupled with normal software supply-chain practice.

Background tasks and safety gates

Background work is where many “agentic” systems become sloppy. In a Teleodynamic reading, background work is allowed only when it stays local, bounded, cancelable, inspectable, and review-visible. Teleodynamic’s local-sandbox guidance explicitly says local execution is not a safety guarantee and rejects blind tools, arbitrary code execution, and private-network probing as defaults. That means background tasks should start as read-only or simulation-only operations such as indexing, summarization, memory compaction, model warm-up, or package verification. Write-capable acts should require explicit elevation.

The resulting rule set is simple and strong: the worker may prepare, score, simulate, summarize, and propose in the background; it may not execute destructive or network-significant actions by default. This is the correct place to operationalize no-op dominance.

Security, privacy, and validation

Security in this design is not a side concern. It is part of the architecture’s meaning. Teleodynamic’s own materials repeatedly draw hard boundaries: no blind tools, no private-network probing, no hidden machine-language authority, no runtime overclaiming, and no treating metadata or theory as execution permission. A faithful desktop implementation must translate that into process isolation, local-only defaults, explicit approvals, and auditable supply-chain handling.

Risk analysis and mitigations

The first row is especially important. PyTorch’s torch.load() documentation says it uses an unpickler under the hood and warns never to load data from an untrusted source; TensorFlow’s save/load docs warn that models are code and require care with untrusted code. That is a strong argument for a desktop policy of safe formats first, conversion in quarantine, raw training artifacts never in the UX process. Hugging Face’s safetensors project is explicitly positioned as a “simple, safe way to store and distribute tensors,” and its format discussion centers safety on avoiding arbitrary code execution and enabling lazy inspection/loading.

For process isolation, Windows gives you meaningful native primitives. AppContainer isolation is designed around least privilege, including file, process, device, and network isolation, and Microsoft says it minimizes opportunities for malicious manipulation by isolating applications from unneeded resources. Job Objects let you manage process groups, enforce limits, collect accounting, and terminate the whole job if necessary. In practice, that means the main WPF process should remain ordinary desktop UI, while one or more workers run at reduced privilege with bounded resources and no inherited broad authority.

The privacy story should be equally explicit. Teleodynamic.com’s public site emphasizes privacy-first, no-tracking posture, and its local-sandbox write-up says local inference reduces privacy exposure and external API dependency but does not eliminate safety risk. So the right desktop guardrail is local logging first, explicit export second, remote sync never by default. If later enterprise features need remote diagnostics, they should be opt-in, separately labeled, and visibly outside local-only mode.

Testing plan and acceptance criteria

The testing plan should mirror the Evaluation Lab’s emphasis on viability, stability, review pressure, and traceability rather than raw correctness alone.

The strongest acceptance criteria are architectural rather than cosmetic. A release should not pass unless: every structural memory change is auditable; every blocked action returns a no-op reason; every tool or background worker is represented by a manifest; the runtime can be killed and restarted without taking down the shell; local-only mode generates no outbound action during inference; and packages can be reconstructed and verified from manifest plus hashes. Those criteria are direct operationalizations of Teleodynamic resource closure, auditability, human review, and no-op dominance.

Roadmap and implementation notes

Because hardware targets, enterprise policy requirements, and exact model mix are unspecified, the roadmap below is deliberately directional. It is ordered to maximize value and containment early.

The minimum viable Teleodynamic feature set should stay intentionally small: local GGUF inference in a worker; local-only mode; goal queue with active goal selection; episodic and semantic memory; explicit split/merge/add/retire/no-op events for memory and goals; approval-required promotions; capability manifests for any tool or background worker; and a visible audit timeline. That is enough to move the app meaningfully from “local chat wrapper” to “bounded teleodynamic operator” without overclaiming.

Recommended libraries

For the .NET 8/WPF stack, the recommended library posture is:

• LLamaSharp as the primary GGUF runtime because it is a local .NET library built on llama.cpp and offers packaged CPU, CUDA, and Vulkan backends.
• ONNX Runtime for embedders, rerankers, safety/policy models, small task models, and custom converted models because it has C# support, broad framework interoperability, and configurable execution providers such as DirectML and CUDA.
• WebView2 for onboarding, model download flows, and documentation-rich surfaces because host initialization and two-way messaging are first-class in WPF.
• Microsoft.Data.Sqlite as the active memory/audit store because it is a lightweight ADO.NET provider that can be used independently of EF Core.
• Named pipes plus System.IO.Pipelines for first-wave worker IPC, with gRPC reserved for cases where strongly-typed, streaming, multi-language workers become valuable.

Sample C# interface sketches

using System.ComponentModel.DataAnnotations;

namespace Teleodynamic.Desktop.Core;

/// <summary>
/// Starts, queries, and stops a local model runtime.
/// Implementations should isolate native runtimes from the UI process when possible.
/// </summary>
public interface IModelHost : IAsyncDisposable
{
    /// <summary>
    /// Starts a runtime host for a specific model package.
    /// </summary>
    /// <param name="options">Startup options for the runtime session.</param>
    /// <param name="cancellationToken">Cancellation signal.</param>
    /// <returns>A handle that identifies the running host session.</returns>
    Task<ModelHostHandle> StartAsync(
        ModelHostStartOptions options,
        CancellationToken cancellationToken = default);

    /// <summary>
    /// Generates a completion from the active runtime host.
    /// </summary>
    /// <param name="request">Generation request including prompt, limits, and budget context.</param>
    /// <param name="cancellationToken">Cancellation signal.</param>
    /// <returns>The generated text plus resource metrics for audit and control decisions.</returns>
    Task<ModelGenerationResult> GenerateAsync(
        ModelGenerationRequest request,
        CancellationToken cancellationToken = default);

    /// <summary>
    /// Retrieves current health and resource information for the runtime.
    /// </summary>
    /// <param name="cancellationToken">Cancellation signal.</param>
    /// <returns>Current health details for the host session.</returns>
    Task<ModelHostHealth> GetHealthAsync(CancellationToken cancellationToken = default);

    /// <summary>
    /// Stops the runtime host and releases its resources.
    /// </summary>
    /// <param name="reason">Human-readable shutdown reason written to audit logs.</param>
    /// <param name="cancellationToken">Cancellation signal.</param>
    Task StopAsync(string reason, CancellationToken cancellationToken = default);
}

/// <summary>
/// Drives bounded goal execution, slow-loop decisions, and explicit approvals.
/// </summary>
public interface IAgentController
{
    /// <summary>
    /// Accepts a user intent and creates or updates the active goal set.
    /// </summary>
    /// <param name="intent">User intent record.</param>
    /// <param name="cancellationToken">Cancellation signal.</param>
    Task<AgentTurnResult> SubmitUserIntentAsync(
        UserIntent intent,
        CancellationToken cancellationToken = default);

    /// <summary>
    /// Advances the controller by one bounded scheduling cycle.
    /// </summary>
    /// <param name="cancellationToken">Cancellation signal.</param>
    Task<AgentTickResult> TickAsync(CancellationToken cancellationToken = default);

    /// <summary>
    /// Applies a human approval or rejection to a pending action.
    /// </summary>
    /// <param name="approval">Approval decision record.</param>
    /// <param name="cancellationToken">Cancellation signal.</param>
    Task ApplyApprovalAsync(
        ApprovalDecision approval,
        CancellationToken cancellationToken = default);
}

/// <summary>
/// Owns active intake memory, promoted semantic memory, and portable .uai packages.
/// </summary>
public interface IMemoryManager
{
    /// <summary>
    /// Appends a new episodic record to the working store.
    /// </summary>
    /// <param name="episode">Episode details.</param>
    /// <param name="cancellationToken">Cancellation signal.</param>
    Task AppendEpisodeAsync(
        EpisodeRecord episode,
        CancellationToken cancellationToken = default);

    /// <summary>
    /// Searches reviewed semantic memory using the supplied query text.
    /// </summary>
    /// <param name="queryText">Query text for retrieval.</param>
    /// <param name="maximumResults">Maximum result count.</param>
    /// <param name="cancellationToken">Cancellation signal.</param>
    /// <returns>Matching semantic memory records ordered by relevance.</returns>
    Task<IReadOnlyList<SemanticMemoryRecord>> QuerySemanticAsync(
        string queryText,
        int maximumResults,
        CancellationToken cancellationToken = default);

    /// <summary>
    /// Performs a bounded compaction cycle that can split, merge, add, retire, or no-op.
    /// </summary>
    /// <param name="request">Compaction policy and budget inputs.</param>
    /// <param name="cancellationToken">Cancellation signal.</param>
    /// <returns>The compaction decision and resulting promotions or refusals.</returns>
    Task<MemoryCompactionResult> CompactAsync(
        MemoryCompactionRequest request,
        CancellationToken cancellationToken = default);

    /// <summary>
    /// Exports a portable .uai package from the current state.
    /// </summary>
    /// <param name="request">Package export request.</param>
    /// <param name="cancellationToken">Cancellation signal.</param>
    /// <returns>The full file path of the exported package.</returns>
    Task<string> ExportPackageAsync(
        UaiPackageExportRequest request,
        CancellationToken cancellationToken = default);
}

/// <summary>
/// Builds structured prompts from goals, memory, policies, and runtime budgets.
/// </summary>
public interface IPromptAssembler
{
    /// <summary>
    /// Assembles a prompt packet for model execution.
    /// </summary>
    /// <param name="request">Prompt context including user input, memory, and budget metadata.</param>
    /// <param name="cancellationToken">Cancellation signal.</param>
    /// <returns>A fully assembled prompt packet ready for a model host.</returns>
    Task<PromptPacket> AssembleAsync(
        PromptAssemblyRequest request,
        CancellationToken cancellationToken = default);
}

/// <summary>
/// Provides a versioned IPC channel for isolated worker processes.
/// </summary>
public interface IWorkerIpcChannel : IAsyncDisposable
{
    /// <summary>
    /// Sends a request to a worker and waits for a correlated response.
    /// </summary>
    /// <param name="envelope">Worker request envelope.</param>
    /// <param name="cancellationToken">Cancellation signal.</param>
    /// <returns>The correlated worker response envelope.</returns>
    Task<WorkerEnvelope> RoundTripAsync(
        WorkerEnvelope envelope,
        CancellationToken cancellationToken = default);
}

/// <summary>
/// Startup options for a model host.
/// </summary>
public sealed class ModelHostStartOptions
{
    [Display(Name = "Runtime Kind")]
    public required string RuntimeKind { get; init; }

    [Display(Name = "Model Key")]
    public required string ModelKey { get; init; }

    [Display(Name = "Model Path")]
    public required string ModelPath { get; init; }

    [Display(Name = "Context Window")]
    public required int ContextWindow { get; init; }

    [Display(Name = "Gpu Layer Count")]
    public required int GpuLayerCount { get; init; }

    [Display(Name = "Maximum Parallel Requests")]
    public required int MaximumParallelRequests { get; init; }

    [Display(Name = "Local Only Mode")]
    public required bool LocalOnlyMode { get; init; }
}

/// <summary>
/// Versioned worker message envelope.
/// </summary>
public sealed class WorkerEnvelope
{
    [Display(Name = "Protocol Version")]
    public required string ProtocolVersion { get; init; }

    [Display(Name = "Message Type")]
    public required string MessageType { get; init; }

    [Display(Name = "Correlation Key")]
    public required string CorrelationKey { get; init; }

    [Display(Name = "Requested Utc")]
    public required DateTimeOffset RequestedUtc { get; init; }

    [Display(Name = "Payload Json")]
    public required string PayloadJson { get; init; }

    [Display(Name = "Budget Token Count")]
    public required int BudgetTokenCount { get; init; }

    [Display(Name = "Requires Approval")]
    public required bool RequiresApproval { get; init; }
}

/// <summary>
/// Minimal semantic memory record.
/// </summary>
public sealed class SemanticMemoryRecord
{
    [Display(Name = "Memory Key")]
    public required string MemoryKey { get; init; }

    [Display(Name = "Topic")]
    public required string Topic { get; init; }

    [Display(Name = "Summary")]
    public required string Summary { get; init; }

    [Display(Name = "Review Status")]
    public required string ReviewStatus { get; init; }

    [Display(Name = "Created Utc")]
    public required DateTimeOffset CreatedUtc { get; init; }

    [Display(Name = "Updated Utc")]
    public required DateTimeOffset UpdatedUtc { get; init; }
}

These sketches are intentionally interface-first. The first implementation can keep them simple: LlamaSharpModelHost, NamedPipeWorkerIpcChannel, SqliteMemoryManager, and DefaultPromptAssembler. The important architectural point is that every path that mutates structure or crosses a trust boundary is explicit in the type system.

References

Primary Teleodynamic and ecosystem sources, prioritized for conceptual meaning and claim boundaries:

• Teleodynamic.com homepage for the high-level definition, resource law, memory strategy, privacy-first stance, and the “not a larger model, a different control regime” framing.
• Teleodynamic Core Concepts for constraint-maintaining intelligence, resource closure, Work-Constraint Cycle, no-op dominance, epistemic firewalls, and preserved hard boundaries.
• Two-Timescale Reference Architecture for the fast-loop/slow-loop model and structural action gating.
• Teleodynamic Agent Capability Framework for the L0–L6 interpretation used to position the MVP at L3/L4 rather than broad autonomy.
• Teleodynamic Claim Boundary Ledger for allowed/prohibited wording and the explicit non-certification posture.
• Teleodynamic–UAIX Boundary Map for lane separation between theory, schema authority, and endpoint/discovery surfaces.
• Offline AI and Local Endpoint Sandboxes for the local-first but not automatically safe posture, including “no blind tools” and no arbitrary code execution by default.
• LocalEndpoint.com and Teleodynamic Architecture for the discovery/validation boundary and the rule that discovery metadata is not execution permission.
• Evaluation Lab for Teleodynamic AI for metric families, review gates, operational viability, human review, and auditability.
• Teleodynamic Autonomy-Washing Red-Team Guide for downgrade rules, resource-trace questions, and no-op/human-review criteria.

Official implementation and platform documentation:

• LLamaSharp repository and NuGet package for local .NET GGUF inference and packaged backends.
• ONNX Runtime official docs for C# support, cross-framework model support, execution providers, plugin EP libraries, and provider selection.
• LiteRT overview for future custom-model/runtime portability considerations and its current language-binding posture.
• WebView2 WPF docs for initialization and host/web messaging.
• Microsoft.Data.Sqlite overview for the SQLite working-store recommendation.
• Named pipes, System.IO.Pipelines, and gRPC on .NET for local-worker IPC design options.
• AppContainer isolation and Job Objects for worker isolation, least privilege, and process/resource governance on Windows.

Model ingestion and distribution references:

• Hugging Face gated models, downloads, ETag-based caching, and model card metadata for download flows, provenance capture, and verification.
• PyTorch torch.load() docs and TensorFlow save/load docs for the “untrusted models are code / unpickling” risk posture.
• safetensors for safer tensor-distribution concepts and lazy inspection/loading.

User-provided design material integrated into this report:

• Adding Direct Custom Model Support to LocalEndpoint Desktop, used here as supporting evidence for a desktop execution plane with modular runtime hosts and worker-based model support.