The agent lifecycle
Follow one piece of work from sign-in to answer, including sessions, context, tool execution, steering, results, objectives, and how memory and evaluated improvements help later work.
This guide follows a user from signing in to receiving an answer. It then explains how later work can benefit from memory and evaluated improvements.
Optional capabilities depend on your project’s configuration and the deployed service version.
The whole journey
1. Get access
A person signs into the dashboard and chooses an organization and project. An application or CLI authenticates with an API key. The key’s permissions decide which operations it can perform.
For CLI access, configure SIKARU_API_KEY. A browser login does not automatically configure your terminal.
Your application also identifies the tenant and end user whose sessions it is managing.
Start with the Quickstart, SDKs, or CLI.
2. Create an agent
An agent is the managed identity you call. Its release is an immutable version of its definition. Supply instructions and definition content, including your authored skills, or select an existing registered release.
Test an agent before relying on it in production. Saving a definition and verifying useful behavior are different steps. See Agents and releases.
One service, many agents and sessions
Sikaru manages the execution infrastructure. Creating an agent with a supported definition does not require you to build a worker image or configure a server. Compatible agents can share the same execution engine while their sessions keep separate conversation state and workspaces.
A release describes agent behavior; an environment describes where its operations run. Sharing an execution engine does not share one user’s conversation or files with another user. Unsupported execution requirements must be made available by the service before the release can run.
Execution is managed by Sikaru by default. You can choose local execution on a connected machine you control. Sikaru selects the underlying managed sandbox.
3. Start a session
A session is a durable conversation. A run is an execution of work. A session can contain multiple turns over time.
A session keeps its release when a newer release becomes active. New sessions can use the new release. Model selection, reasoning controls and a final-output schema are available through the supported request fields and project configuration. A valid output shape does not by itself prove a correct answer.
Keep the returned session, run and input IDs. Use idempotency keys when retrying the same operation. See Sessions and steering.
4. Prepare context and do the work
The agent assembles the information needed for its next model call. This can include instructions, recent conversation, a summary of older context, allowed tools and relevant scoped memory when enabled.
The harness is the execution engine behind the agent. The model generates responses and proposed actions; the runtime applies policy and coordinates execution.
Long conversations may be summarized to fit the model’s context budget. The working prompt is not the complete retained history.
A manager can delegate a focused task to a named child agent, provide the necessary context, steer it, and use its result. Delegation does not mean the child automatically receives the parent’s entire conversation.
5. Choose where tools execute
Local compute runs admitted operations on your machine while agent orchestration remains hosted. The native executor must be running to handle its requests. See Local compute.
For product-owned tools, your application executes the action and submits its result. Approval alone does not execute it.
If you lose an acknowledgement after an external action, check whether it happened before retrying. See Runs and tool requests.
6. Change direction or stop
Steering is the default during active work. Input arriving too late is retained as a follow-up. Already executed actions are not undone by a new instruction.
Closing the CLI or reaching a client timeout does not cancel hosted work. Request cancellation explicitly. Recovery uses saved progress and receipts; it does not reverse external effects.
7. Collect results and continue
Outputs can include an answer, files and retained artifacts. Download them through authorized APIs. File deletion is explicit; historical filesystem versions have a separate retention lifecycle.
A branch is a new conversation based on a recorded snapshot. It does not duplicate live pending actions or undo actions already taken. Shared user memory is not rewound when you branch.
See Files and artifacts and Session branching.
8. Define success and automate follow-up
An objective describes a desired outcome and checks its evidence. Producing a final answer and satisfying an objective are separate events. A schedule admits future work; a webhook reports an event to your application.
Missing evidence is not success. Pausing an objective does not cancel an active run. See Objectives, Schedules, and Webhooks.
9. Memory and improvement
When enabled, scoped memory can help later work reuse relevant preferences and knowledge. Memory is selected information, not a copy of every past conversation in every prompt.
The service evaluates changes before admitting them. An improvement to a reusable release does not replace the pinned release of an existing session. Private optimization details remain service-owned.
To opt in at startup, add --auto-improve to sikaru runs start or sikaru execution-sessions create. It is off by default and requires the appropriate permission and a configured learning policy. Eligible work is processed asynchronously; the flag does not guarantee that every run immediately produces a new release. See the CLI guide.