Nimi

English

中文

English

中文

Appearance

Agent Execution ​

Status: Mixed. RuntimeAgentService is the runtime authority for supported agent chat and lifecycle. Life Track and hooks are partial: the first release promise covers narrow follow-up-turn only, not general reminders or app scheduler ownership.

RuntimeAgentService is the runtime-owned authority for agent execution. It owns multi-agent lifecycle, conversation continuity, supported Chat Track execution, narrow follow-up-turn hook admission, memory admission policy, and presentation projection. Broader Life Track autonomy, general reminders, appointments, and app-authored scheduling are outside the first release promise.

This page is the runtime-side overview. For depth see:

What RuntimeAgentService Owns ​

ResponsibilitySurface
Multi-agent lifecycleConcurrent agent_id lifecycles
Conversation continuityConversationAnchor per agent + per conversation
Chat / Life track executionReactive chat + partial narrow follow-up-turn path
Hook schedulingTyped HookIntent admission and dispatch for narrow follow-up-turn only
Memory write admissionBounded by admitted memory contracts
Presentation projectionPersistent profile + transient stream
APML output parsingTyped event projection from APML wire format

There is no platform default current agent. The runtime hosts multiple agent_id lifecycles concurrently; an app or surface selects which agent it is interacting with.

ConversationAnchor ​

The conversation anchor is the runtime-owned continuity identity that lets multiple surfaces share one conversation without collapsing into a global session.

PropertyValue
ScopePer-agent + per-conversation
OwnerRuntime
PersistenceSurvives surface switch (Desktop chat → Avatar → Web)
MultiplicityOne agent can have multiple anchors (multiple parallel conversations)

For the product framing, see Platform → Agents → Conversation Anchor.

AgentPresentationProfile ​

The persistent presentation profile is runtime-owned, slow-changing truth about how an agent is presented:

FieldPurpose
Avatar backendLive2D / VRM / generated-motion
Asset referenceCarrier-specific asset binding
Expression presetDefault expression behavior
Voice bindingVoice profile reference

The profile survives runtime restart and cross-surface reuse. Avatar consumes it; Avatar doesn't redefine it.

Agent Presentation Stream ​

Distinct from the persistent profile, the presentation stream is the transient projection seam: turn projection, current emotion projection, stream commit semantics. This is what Avatar consumes turn-by-turn for embodied surfaces.

OwnerRuntime
Turn projectionruntime.agent.turn.*
Activity eventsruntime.agent.activity.*
Posture eventsruntime.agent.pose.*
Lipsync framesruntime.agent.lipsync.*

APML Output Wire Format ​

The model-facing contract for agent output is APML (Agent Personality Markup Language).

Root tagPurpose
<life-turn>Proactive life-track output
<chat-track-sidecar>Reactive chat-track sidecar
<canonical-review>Canonical review output for memory admission

JSON executor compatibility is not admitted. APML is parsed and projected into typed runtime events before any product code sees it. Apps consume the typed events, not raw APML.

This is a deliberate design: the model emits structured agent output; runtime validates the structure; product code receives typed events that cannot encode shapes the runtime did not admit.

Hook Intent Admission ​

Agents request narrow follow-up-turn action through typed HookIntent records, not free-form scheduling strings. Runtime validates and admits only the release-promised follow-up-turn path.

Lifecycle stateMeaning
pendingAdmitted; awaiting fire time
runningCurrently executing
completedSuccessful terminal
failedFailed terminal
canceledCanceled before completion
rescheduledMoved to new schedule; transitions back to pending
rejectedRefused at admission

For the product framing, see Platform → Agents → Hook Intent.

Multi-Agent By Default ​

Runtime hosts multiple agent_id lifecycles concurrently. An app that wants to interact with a specific agent provides the agent_id; runtime does not assume which agent.

ConcurrencyDetail
Per-agent stateEach agent has its own anchor set, partial follow-up-turn hook state, presentation profile
Per-conversation stateEach conversation has its own anchor
Cross-agent isolationMemory bank scopes (AGENT_CORE / AGENT_DYADIC) keep agents from reading each other's private state
Concurrent executionMultiple agents can run supported Chat paths; broader Life concurrency is outside the first release promise

Reader Scenario: Two Agents In One Surface ​

A user has two agents on a single Desktop window — perhaps a project assistant and a personal assistant. Both can act concurrently.

  1. Each has its own lifecycle. Runtime tracks both agent_ids independently.
  2. Each has its own anchors. The user has separate conversations with each.
  3. Each has its own life track. Both can have life enabled independently; their token budgets do not pool.
  4. Their memory is scoped. AGENT_CORE for each is private; they do not see each other's private memory.
  5. Audit lineage preserves which agent took which action.

Two agents under one user; no shared state by default.

Reader Scenario: A Conversation Anchor Survives Crash ​

User is in a conversation in Avatar. Avatar crashes.

  1. The anchor lives in Runtime. Not in Avatar; not in Desktop.
  2. User reopens Avatar. Avatar reconnects to runtime.
  3. Anchor resolution. Avatar resolves the same (agent_id, conversation_id); the anchor is still there.
  4. Conversation resumes. Realm chat thread retains messages; memory writes that were in flight follow replication state.

The anchor's runtime ownership is what makes surface failure survivable.

Source Basis ​

Nimi AI open world platform documentation.

Copyright 2026-present Nimi Platform