AI Agent Runtime

A shared foundation for durable, tool-using AI applications across desktop, server, workspace, and domain-specific products.

Abstract

RemObjects Infrastructure's AI Agent Runtime has grown from a set of model clients and chat helpers into a reusable agent platform. Its central idea is simple: applications should not each reinvent durable AI execution, tool dispatch, approvals, progress reporting, question handling, child agents, skills, model routing, usage tracking, and transcript projection. Those concerns now live in one shared Infrastructure layer, while each host supplies its own domain context, UI or transport, tools, profiles, and persistence policy.

This document gives a source-backed overview of that system. The first part explains the runtime architecture, the execution model, the shared function and interaction system, the skill layer, orchestration, persistence, and the two host models: SingleSessionHost and MultiSessionHost . The second part shows how the same platform supports four different products today: CodeBot for Elements in Fire and Water, CodeBot Server for CodeBot for Delphi, Campfire, and Alf. The goal is both explanatory and promotional: this is a practical technology platform for building AI-enabled applications without starting from a blank page each time.

Executive Summary

Infrastructure AI provides a headless, durable, tool-using agent runtime. It is "headless" because it does not own a chat window, web socket, SSE protocol, IDE panel, or product-specific object model. It is "durable" because work is represented as threads, runs, events, approvals, questions, child runs, and snapshots rather than as one transient model call. It is "tool-using" because all model-facing tools flow through the shared FunctionDefinition and ImplementedFunctionDefinition system already used by classic chat, MCP integration, and host-defined functions.

The runtime lets consumers define agent profiles. A profile combines instructions, a model policy, available tools, allowed child profiles, context contributors, streaming behavior, and timeouts. A host submits a user message to a thread, the runtime creates a run, the worker advances that run, model calls are made through provider-neutral clients, tools execute through strongly typed function contexts, and every meaningful state transition is emitted as an AgentEvent . Hosts then render or transmit those events however their product requires.

The host layer deliberately supports two shapes:

• SingleSessionHost is for local, interactive applications that own one foreground conversation at a time, such as an IDE side pane or a workspace assistant.
• MultiSessionHost is for services that keep many user sessions alive over one shared runtime and worker, such as web/API servers or multi-tenant chat backends.

Both sit on the same SessionHost base, so capabilities such as approvals, questions, annotations, progress, skill support, model strategy selection, usage tracking, orchestration hooks, and run finalization do not have to be rebuilt separately.

Architectural Overview

At the highest level, Infrastructure AI separates three responsibilities that are often tangled together in product-specific AI code.

First, the model layer knows how to talk to providers. It exposes AIClient , Message , ToolCall , provider implementations, model references, and model policies.

Second, the function layer knows how to describe and execute tools. It exposes FunctionDefinition , ImplementedFunctionDefinition , FunctionExecutionContext , MCP function providers, approvals, questions, progress, and annotations.

Third, the agent layer knows how to run work over time. It exposes AgentRuntime , AgentWorker , stores, profiles, threads, runs, events, snapshots, orchestration, child agents, recovery, and host integration.

The system is intentionally layered but not abstract for abstraction's sake. Each layer carries real operational weight. The runtime is where runs are queued, leased, resumed, canceled, failed, or completed. The host base is where product sessions become function execution sessions. The function layer is where user-facing safety and interactivity are normalized. The skill layer is where app, language, project, workspace, legal, or workflow context becomes reusable instructions and tool behavior.

Runtime Data Model

The agent runtime is built around a small number of durable concepts.

An AgentThread is the user-visible conversation container. It has an ID, title, kind, default profile, and timestamps. A thread does not execute work itself. It groups runs and gives the host a stable conversation identity.

An AgentRun is one unit of work. Root runs correspond to user submissions. Child runs correspond to delegated agent work, usually created through spawnAgent . Runs record their thread, root run, parent run, tool call relationship, profile name, initial prompt, status, model attempts, message history, pending actions, pending child runs, final assistant text, cancellation flag, lease state, and error state.

An AgentEvent is the durable audit trail. Events cover submitted user messages, queued runs, run status changes, assistant messages and deltas, tool calls, annotations, approvals, questions, child runs, progress, model fallback, remote activity, and usage capture.

An AgentSnapshot is the host-facing projection. It contains the thread, ordered runs, pending approvals, transcript items, updated timestamp, and active run ID. Hosts generally render snapshots and incremental events instead of poking at raw run internals.

This data model is the key difference between a chat helper and an agent runtime. A chat helper produces one answer. The agent runtime records how the answer happened, what work is still blocked, what the user must approve or answer, what child agents are active, and how the host can recover if the process restarts.

Execution Lifecycle

Execution begins when a host creates or resolves a thread and submits a prompt. AgentRuntime.SubmitUserMessage creates a queued root run, records the user message event, and records the queued event. AgentWorker then pumps queued work. When it claims a run, the runtime resolves the profile, initializes the message history, adds profile instructions and context contributor messages, builds the available tool catalog, and sends the request to the selected model.

If the model returns plain assistant content, the runtime stores the assistant message and finalizes the run. If the model returns tool calls, the runtime processes each call. Read-only tools execute immediately. Mutating or external tools may require approval unless host policy auto-approves them. A spawnAgent tool call creates child runs and puts the parent run into WaitingForChildren . A function-level question puts the run into WaitingForInput . When the user answers, approves, rejects, or cancels, the runtime resumes or completes the pending callback and requeues the run when appropriate.

Model failure is not a terminal condition by default. A profile's AgentModelPolicy can include a primary model and fallback models. The runtime tries models in order and emits model fallback events so hosts can show what happened.

The important design point is that every branch goes through the same state machine and event system. A product can choose whether to render a question as radio buttons, send it over SSE, display a native modal, or auto-deny in non-interactive mode, but the runtime does not need a separate version of "question handling" for each product.

Profiles, Models, and Orchestration

AgentProfile is the runtime's unit of agent specialization. A profile contains:

• Name and DisplayName
• instructions
• an AgentModelPolicy
• directly registered tools
• function providers
• allowed child profiles
• context contributors
• streaming and timeout settings
• optional orchestration metadata

This makes profiles a clean boundary between shared runtime behavior and product intent. CodeBot can have a code writer profile, a reviewer profile, a debugger profile, a completion profile, and a smart paste profile. Alf can have a legal research profile, dossier profile, workflow builder, reviewer, worker, and form extraction profile. The runtime does not need to know what these mean. It only needs to know their instructions, model policies, tools, context, and allowed children.

Model routing is similarly abstract. ModelRef identifies a provider and model. AgentModelPolicy supplies the primary and fallback choices. ModelStrategy and ModelStrategyRegistry allow hosts to route by capability rather than hard-coding every profile to one concrete model. CodeBot, for example, can define capabilities such as lightweight, general, coding, review, and deep reasoning, then map each capability to one or more models with approval gates for unusually expensive choices.

Orchestration adds a higher-level control loop on top of profiles. The shared orchestration system can analyze a message, route it to a profile, plan work, execute work, check goal alignment, review work, and continue when a checker says more work is needed. Hosts customize the policy, profile names, prompt text, command routes, and state transitions. The result is not one hard-coded agent workflow, but a reusable framework for product-specific workflows.

That orchestration layer is deliberately host-tunable. A local attended IDE session may ask before risky product choices and show intermediate progress. A server can group queued messages, preserve slash-command intent, and continue work across SSE reconnects. A non-interactive integration can deny or approve selected interactions by policy and expose a different event sink.

Functions, Approvals, Questions, Progress, and Annotations

Infrastructure AI treats tool execution as a first-class shared system. Tools are not ad-hoc JSON blobs that each app interprets independently. They are FunctionDefinition or ImplementedFunctionDefinition instances with schemas, descriptions, access levels, availability checks, signatures, timeouts, and execution callbacks. Tool providers can be host-defined, MCP-backed, skill-provided, or composed from existing classic chat functions.

FunctionExecutionContext is the bridge between a tool and its host session. It carries metadata, cancellation, timeout budget, the execution session, and callbacks for progress, questions, approvals, and annotations. That context lets a function remain portable while still participating in a rich host interaction model.

The interaction model has several important pieces:

• Progress can be indeterminate or determinate. A function can report a message, stage, current count, total count, unit, and computed percentage.
• Questions can be buttons, single-choice, multiple-choice, or free text. AskQuestionFunction exposes that capability directly to models in interactive contexts.
• Approvals include scopes, duration, danger flags, approval type, scope data, and optional annotations. Grants can be once-only, session-scoped, or persistent.
• Annotations can be text annotations, diff annotations, and new-file annotations. Approval annotations carry pending, approved, or rejected decisions so a UI can show not just what changed, but whether the user accepted it.
• MCP tool annotations map into Infrastructure function access levels so external tool ecosystems can participate in the same safety model.

This unified interaction model is one of the largest practical benefits of the platform. A product that adopts Infrastructure AI does not need to invent its own "ask the user" protocol, its own approval cache, its own progress object, its own diff preview shape, or its own MCP tool semantics. It can flatten these Codable objects to JSON, render them natively, or forward them to a client while preserving the shared behavior.

Skills and Context

The skill layer provides reusable behavioral and tool guidance that can be selected from session context. AgentSessionContext carries app name, languages, active file extension, tags, and other host-provided facts. A host-specific context can implement additional interfaces, such as code-session context for IDE-style code tasks. SkillManager uses that context to discover, filter, auto-load, and inject skills.

Skills can come from global sources, workspace or solution sources, database-backed sources, application resources, or other SkillSource implementations. They can be agent-only, manually loadable, automatically loaded by context, or writable depending on the host and source. SessionHost provides shared support for UseSkill , UnloadSkill , skill source availability checks, skill state persistence hooks, and skill-management approvals.

This is a key part of the product story. The runtime does not just give applications "a chat model." It gives them a way to carry local conventions, domain policy, project shape, language style, and user-provided guidance into the agent loop without baking that knowledge into the runtime itself.

Persistence, Recovery, and Usage Tracking

IAgentStore is the persistence seam for threads, runs, events, approvals, and snapshots. The runtime can use an in-memory store, a JSON store, or a host-backed store. Hosts then choose how much durability they need. A local IDE can persist a cached chat state beside the solution. A server can keep active state in memory and mirror product session state elsewhere. Alf can persist runtime state to a file store and/or database depending on configuration.

Recovery is part of the runtime. ReconcileRecoverableRuns walks non-final runs and repairs states that can safely continue. Running runs whose lease expired can return to queued. Runs waiting for children can resume once all pending child runs are final. Runs waiting for approval can resume if the pending approval state changed while offline. Runs waiting for input without a live callback fail explicitly, because the missing callback is not recoverable.

Usage tracking is integrated at the host layer. SessionHost can start, update, and finish UsageRunRecord objects. It captures run IDs, session IDs, thread IDs, initial prompt, profile, origin, request metadata, model usage, pricing, cost, and injected skill names. This lets consuming products show cost and usage behavior without retrofitting accounting into every model call.

The Shared Host Base

SessionHost is the common base that keeps the single-session and multi-session models from drifting into separate systems. It owns the common host contract:

• approving and rejecting approvals
• answering and canceling questions
• canceling background runs
• skill loading and unloading
• model strategy configuration
• agent session context creation
• skill context injection
• orchestration hooks
• dispatcher hooks for UI and background work
• event dispatch hooks
• usage tracking
• approval annotation decision updates
• function execution session resolution

It also defines SessionHostState , the host-side execution session object. This state has a stable session ID, interactivity flag, foreground thread ID, active run ID, key-value state, run contexts, run modes, final responses, and usage records. In other words, the runtime's durable graph remains product-neutral, while SessionHostState is the host-facing binding that tools can see through FunctionExecutionContext.Session .

The base class is intentionally not a product. It does not know how Fire renders HTML, how CodeBot Server emits SSE, or how Alf persists chat history. It provides the common hooks and helpers so those products can specialize behavior without duplicating the fundamentals.

Host Model One: SingleSessionHost

SingleSessionHost is designed for local, interactive applications that own one foreground conversation. It creates and owns its runtime, worker, event bus, store, current foreground thread, host session, and cached state. It is a natural fit for an IDE panel, a document window, or a workspace assistant where one human is interacting with one local surface.

It provides local application behavior:

• UpdateSettings creates or refreshes the runtime when accounts, models, skills, or settings change.
• ExecutePrompt submits a foreground or background run, optionally through orchestration.
• Cancel cancels foreground work without treating background runs as part of the same cancel scope.
• CancelBackgroundRun is available when a host wants to cancel a specific background run.
• StartNewChat clears cached state, store state, visual state, skills, and run state for a new local conversation.
• Cached state can be restored synchronously or asynchronously.
• UI subclasses can track busy state, streaming text, incoming usage, tool activity, questions, approvals, annotations, and run completion.

SingleSessionHost is not "less capable" than the multi-session model. It is optimized for one local session where the host can keep direct references to UI state and persisted local cache state. It still uses the same runtime, profiles, tools, approvals, questions, annotations, progress, skills, child agents, orchestration, model fallback, and usage tracking.

Host Model Two: MultiSessionHost

MultiSessionHost is designed for servers and services. It accepts an injected runtime and worker, subscribes to the runtime event bus, and maps arbitrary session keys to SessionBinding objects. Each binding records the session key, foreground thread ID, thread kinds, active run, run contexts, run modes, final responses, usage records, and per-session profiles.

The multi-session host adds service-oriented behavior:

• EnsureSession lazily creates a session binding and foreground conversation thread for a session key.
• ExecutePrompt submits work for a specific session key.
• RegisterSessionProfile allows the same runtime to resolve different profile sets per session.
• SessionForThread and SessionForRun map runtime events back to the correct product session.
• CancelSession cancels active foreground work for one session without stopping the whole host.
• ReleaseSession removes run, thread, web/session, and tool-call mappings for a closed session.
• PendingRootRunCount exposes queue pressure per session.
• Event handlers receive the resolved session binding so subclasses can write to SSE queues, databases, event queues, or compatibility chat histories.

The central design difference is ownership. A single-session host owns a local runtime as part of one UI surface. A multi-session host owns or receives one runtime for many sessions and must route every event, profile lookup, function execution context, and user response through session mappings.

Area	SingleSessionHost	MultiSessionHost
Primary use case	Local interactive app, one foreground conversation	Server/service, many concurrent product sessions
Runtime ownership	Usually created and refreshed by the host	Injected/shared runtime and worker
Session identity	One default host session	Many SessionBinding objects keyed by session
Foreground thread	One current foreground thread	One foreground thread per session
Background work	Separate background threads tracked locally	Background threads mapped to the owning session
Profiles	Registered globally in the local runtime	Registered per session, resolved by thread/run
Event rendering	Usually direct UI/HTML rendering	Usually transport/event queue/SSE/database
Cache/persistence	Local cached state and visual restore	Session release, reconnect, server state, product stores
Best fit	IDE side pane, document assistant, workspace app	Web/API server, multi-tenant service, chat backend

The two host models are deliberately parallel where they should be parallel and different where they must be different. Shared interaction, skill, orchestration, and usage behavior belongs in SessionHost . Session routing, profile scoping, and transport-specific event handling belong in the derived host.

Part II: Current Consumers

The strength of a platform shows up in the range of applications it can support. Infrastructure AI currently supports four notably different consumers. They share the same runtime and function model, but they use different host shapes, session contexts, tools, profiles, UI transports, and persistence policies.

CodeBot for Elements in Fire and Water

CodeBot for Elements is the local IDE assistant hosted by Fire and Water. It uses CodeBotSingleSessionHost , which derives from HtmlSingleSessionHost , which derives from SingleSessionHost . This stack is a good example of how a product can add a polished UI and deep IDE context without forking the runtime.

The shared CodeBot layer configures global and per-solution stores for approvals, memories, MCP connections, and usage. It creates a CodeBotSingleSessionHost , assigns a solution usage store, updates settings from the selected AI account, and restores cached session state. The host resolves model clients from the current account and can either use a named model strategy or build a single-model strategy from the selected account/model.

The IDE-specific session context is rich. It includes the host app name, active language, active file extension, Elements RTL tags, platform tags, SDK tags, cross-platform hints, and Island Delphi hints. This context lets skills and prompts adapt to the actual solution state instead of treating every task as generic text.

CodeBot's profile catalog is broad:

• codebot for normal conversation and coordination
• messageAnalyzer for routing
• planner
• questionAnswering
• goalAlignmentChecker
• genericTask
• codeWriter
• codeReviewer
• securityReviewer
• codebaseAnalyzer
• codeWritingSubagent
• debugging
• Fire-private codebotCompletion
• Fire-private codebotSmartpaste

The debugging profile is a particularly strong demonstration of specialization. It can use IDE debugger tools, breakpoints, stack frames, locals, registers, expression evaluation, disassembly, debug console commands, and output/state polling. This is not a generic chat prompt. It is a profile with a specific operational charter and a specific tool environment.

HtmlSingleSessionHost turns runtime events into CodeBot's chat surface. It renders assistant messages and streaming deltas, tool call activity, completed tool calls, approval and question controls, progress, annotations, child agent activity, run status messages, waiting-for-child-agent messages, and usage updates. Because all of this arrives as AgentEvent objects, the UI code focuses on presentation rather than reconstructing runtime semantics from raw model responses.

For Fire and Water, the benefit is product depth. CodeBot can participate in the actual IDE: inspect projects, read and edit files, build, debug, use MCP tools, apply skills, ask focused questions, show diff annotations, require approvals, and track costs. At the same time, it remains on the same runtime used by server-side and non-IDE products.

CodeBot Server for CodeBot for Delphi

CodeBot Server is the server-side host for CodeBot for Delphi. It uses CodeBotMultiSessionHost , which derives from MultiSessionHost . This is the clearest example of the multi-session model: many Delphi client sessions connect to one server process, and the host maps each product session to an agent session key, foreground thread, runtime runs, queued messages, remote tool calls, and SSE events.

CodeBotMultiSessionHost creates an AgentRuntime backed by an in-memory store and a server worker. Incoming web sessions are remembered, assigned session IDs, and bound to runtime sessions. Submitting a user message records usage metadata such as endpoint, caller, correlation ID, account, project ID, project name, and project fingerprint. The host then builds or reuses an orchestration request, optionally groups queued plain-text follow-up messages, submits the prompt to the runtime, and emits queued status over the session event queue.

The server specializes event handling for transport. Assistant deltas are buffered and flushed into public messages. Client-dispatched tools become toolCall SSE events. Tool results become toolResult SSE events. Internal tool calls become user-visible status messages. Approvals, questions, annotations, progress, child runs, model fallback, final events, queue positions, and blocking states are flattened into the server's streaming contracts.

The host also bridges remote IDE tools. Some tool calls execute on the server. Others are dispatched to the Delphi client and later completed through /v1/tool_result -style handling. The host remembers runtime tool call IDs, expected sessions, client-dispatched state, arguments, expiration, and early completions. This allows the runtime to see a normal function result even when the actual work happened in an external IDE client.

Profile-wise, CodeBot Server mirrors the CodeBot architecture while adapting it for server operation and Delphi-oriented context. It defines a main codebot profile, orchestration profiles, code writer, code reviewer, security reviewer, codebase analyzer, generic task, question answering, and code-writing subagent roles. It uses CodingAgentOrchestrationPrompts and CodeBot-specific addenda, but it does not own a local IDE UI. Its product contribution is session routing, transport flattening, queued-message semantics, remote tool bridging, and server-side safety.

The benefit is strategic: CodeBot Server no longer needs to maintain a separate agent system. It can keep its server-specific API and compatibility behavior while relying on Infrastructure AI for durable runs, child agents, approvals, questions, annotations, skills, model fallback, orchestration, and usage.

Campfire

Campfire is the standalone workspace assistant. It shares the CodeBot local host stack, but it changes the domain from "Elements solution inside an IDE" to "folder-based workspace." In source terms, Campfire uses the shared CodeBot and CodeBotSingleSessionHost machinery with CodeBotHostKind.Campfire , plus Campfire-specific functions, settings, workspace state, and prompts.

The Campfire profile intentionally avoids solution/project assumptions. Its instructions emphasize workspace tools: get workspace information, list workspace folders, read files and line ranges, create files, replace text, replace whole files when appropriate, rename or delete files when explicitly requested, and use Campfire's Git tools for repository work. It also supports workspace-local skills from locations such as .codex/skills , .claude/skills , .agents/skills , and Campfire workspace skills.

This is an important proof point for Infrastructure AI. The same single-session host that supports an IDE can also support a lighter workspace app. Campfire still gets approvals, questions, skill loading, MCP integration, progress, annotations, usage tracking, child agents, orchestration, and persistent local state. But the available tools, system prompt, file links, Git expectations, workspace context, and product storage are Campfire-specific.

For users, Campfire feels like a focused coding workspace assistant rather than a full IDE feature. For developers, it avoids a second AI architecture. The product-specific code stays at the boundaries: workspace file functions, Git functions, workspace settings, UI controller, and host prompt policy.

Alf

Alf demonstrates that Infrastructure AI is not limited to code editors. AlfAgentHost derives from MultiSessionHost and adapts the runtime to a legal and workflow-oriented product. Its sessions are AlfSession objects keyed by chat ID. It can persist session state to a database and/or file store, load skills and MCP connections from database-backed sources, send events through an Alf event queue, and translate completed runs into Alf chat messages.

The profile catalog is domain-specific:

• alf for the main assistant
• legalResearch
• dossierAssistant
• workflowBuilder
• worker
• reviewer
• contextAnalyzer
• workerSubagent
• documentFormExtraction
• shared orchestration roles such as message analyzer, planner, question answering, goal alignment checker, and generic task

Alf uses the same function, skill, and event primitives but applies them to legal research, dossier work, workflow building, document/form extraction, and service-specific execution. Its AgentSessionContext adds tags such as Alf, legal, workflow platform, language, location, dossier, workflow, service, and email. That context can drive skill auto-loading and prompt shaping in the same way Fire's context can drive language and platform skills.

Alf also shows how a host can bridge new runtime events into an existing product protocol. Tool calls can be represented as compatibility messages. Assistant responses are stored in Alf message history. Approval and question events are sent through the event queue with callbacks that call back into Approve , Reject , AnswerQuestion , or CancelQuestion . Progress, annotations, and agent activity use the same event payload structure.

The benefit is breadth. A platform originally motivated by coding assistance can support legal/workflow automation because its primitives are not code-specific. Threads, runs, profiles, model policies, tools, questions, approvals, progress, annotations, child agents, events, snapshots, skills, and host sessions are general enough to serve a different domain.

Benefits for New Consumers

A new consumer adopting Infrastructure AI gets several advantages immediately.

First, it gets durable execution instead of one-shot chat. Work can run in the background, wait for approval, wait for user input, wait for child agents, recover after interruption, emit status, and produce a transcript.

Second, it gets safety as a platform feature. Tool access levels, approval requests, approval scopes, dangerous-action handling, persistent grants, session grants, annotations, and model approval requirements all live in shared code. A host can tune policy without inventing the machinery.

Third, it gets a common interaction vocabulary. Questions, progress, annotations, approvals, assistant deltas, tool calls, child runs, fallback events, and final statuses have structured shapes. A web app can serialize them to JSON. A desktop app can render them natively. A test can assert on them directly.

Fourth, it gets model abstraction without losing control. Profiles choose policies, policies choose providers and models, strategies can route by capability, and fallback is built into execution. Expensive or sensitive models can require approval.

Fifth, it gets tool reuse. Host functions, MCP tools, skill functions, classic chat functions, and agent-specific functions all converge on ImplementedFunctionDefinition . A tool can participate in cancellation, timeout pausing, progress, question asking, approval, and annotation without custom glue per app.

Sixth, it gets skill-driven context. Product, workspace, solution, language, legal, workflow, and user guidance can be modeled as session context and skills. This keeps the runtime generic while making the actual assistant feel native to the product.

Seventh, it gets two deployment models. A local app can start with SingleSessionHost . A server can start with MultiSessionHost . Both share the same runtime primitives, so moving concepts between them does not mean rewriting the whole stack.

Adoption Pattern

The recommended adoption path is straightforward.

1. Choose the host model. Use SingleSessionHost for one local interactive surface. Use MultiSessionHost for many sessions or a server process.
2. Define the session context. Decide what app name, language, project, workspace, domain, tags, and state the skill layer should see.
3. Register profiles. Start with a main profile and add specialized profiles only where they have distinct instructions, tools, models, or child-agent rules.
4. Add function providers. Expose product tools as ImplementedFunctionDefinition instances and classify access correctly.
5. Wire interactions. Decide how approvals, questions, annotations, progress, and status events should render or serialize.
6. Choose stores. Pick in-memory, JSON, file-store, database, or host-specific persistence based on recovery requirements.
7. Add skills. Connect global, workspace, solution, database, or embedded skill sources and let AgentSessionContext select the right ones.
8. Add orchestration only where it earns its keep. Use direct profiles for simple products; add analyzer/planner/executor/checker/reviewer loops when tasks are multi-step or benefit from role separation.
9. Track usage. Attach a UsageStore early so model cost, pricing, profile, session, and skill information are captured from the start.

This path lets a new product begin small and then grow into deeper agentic behavior without changing foundations.

Conclusion

Infrastructure AI is now a product platform, not just an implementation detail. It gives RemObjects applications a shared vocabulary for agent execution: profiles, threads, runs, tools, events, approvals, questions, annotations, progress, child agents, skills, snapshots, usage, and host sessions. It also gives product teams a practical choice of host model. A local interactive product can build on SingleSessionHost ; a server or service can build on MultiSessionHost ; both inherit the common behavior from SessionHost .

The four current consumers show why this matters. Fire and Water use the runtime for a deeply integrated IDE assistant. CodeBot Server uses it to coordinate many Delphi client sessions over server transports. Campfire uses it for a workspace-first coding app. Alf uses it for legal and workflow assistance. These are different products, but they no longer need four separate AI runtimes.

For future consumers, the promise is clear: bring your domain model, tools, UI, and persistence needs; Infrastructure AI supplies the durable agent substrate. That substrate is already tested across local desktop, server, workspace, and domain-specific service scenarios. The more products build on it, the more shared capabilities improve for everyone.