little_ghost 0.2.1 → 0.4.0

data/docs/guides/getting_started.md

@@ -1,33 +1,62 @@
-# Getting Started with LittleGhost
+# Getting Started
 
-This guide builds a customer support agent that checks a small help center before answering. It focuses on the Ruby objects needed for one useful run: a tool, an agent, and the call that starts it.
+In this guide, you'll run an agent, connect it to a small help center, and stream its answer. The whole feature stays in ordinary Ruby.
 
-LittleGhost runs inside your Ruby process. It does not choose how your application is hosted or where these definitions live.
+## Install the gem
 
-## Install LittleGhost
-
-LittleGhost requires Ruby 3.3 or newer. Add the gem to your `Gemfile`:
+LittleGhost requires Ruby 3.3 or newer. Add the gem to your `Gemfile`, install it, and set a provider credential:
 
 ```ruby
 gem "little_ghost"
 ```
 
-Install the bundle and set a provider credential:
-
 ```sh
 $ bundle install
-$ export OPENAI_API_KEY="..."
+$ export OPENROUTER_API_KEY="..."
 ```
 
-With `OPENAI_API_KEY` present, LittleGhost can connect the `openai` provider name used below. OpenRouter credentials work as well. Use application secret management outside a local shell, and do not commit provider credentials.
+Use your application's secret manager outside a local shell, and never commit provider credentials.
+
+This guide uses OpenRouter because one credential is enough to begin. LittleGhost can use other provider connections too; you will configure those in [Running in Production](production.md).
 
-## Give the agent a tool
+## See your first answer
 
-Start by requiring LittleGhost and defining a narrow help center lookup:
+Create `customer_support_agent.rb`:
 
 ```ruby
 require "little_ghost"
 
+class CustomerSupportAgent < LittleGhost::Agent
+  model "openrouter:openai/gpt-5.6-luna"
+  system_prompt "Answer customer questions clearly and concisely."
+end
+
+run = CustomerSupportAgent.ask("Can I change the address on my order?")
+
+if run.completed?
+  puts run.response
+else
+  warn "Support request ended as #{run.outcome}: #{run.error&.class}"
+end
+```
+
+Run the file and you have a working AI feature:
+
+```sh
+$ ruby customer_support_agent.rb
+```
+
+`CustomerSupportAgent.ask` creates a `LittleGhost::Run` for this request. When the work finishes, the Run holds the outcome and response.
+
+The inline prompt keeps this first example easy to see in one place. When the instructions grow, [Prompts as Views](prompt_views.md) moves them into a conventional ERB file without adding setup to the Agent.
+
+The selected external provider may receive system instructions, caller input, conversation history, tool results, and attachments. Model wording can vary, so use application code—not a prompt—when a rule must always hold.
+
+## Connect the agent to your application
+
+The first agent can answer general questions. A **tool** gives it a focused operation backed by your Ruby code:
+
+```ruby
 class HelpCenterLookupTool < LittleGhost::Tool
   HELP_CENTER_ENTRIES = {
     "refunds" => "Refunds are available within 30 days of purchase.",
@@ -50,61 +79,86 @@ class HelpCenterLookupTool < LittleGhost::Tool
 end
 ```
 
-A tool gives the model one application operation with a name, description, and validated JSON input. LittleGhost validates the input before calling `#call` and turns the returned value into model context.
-
-The schema checks shape, not authorization. A tool that reads customer data or performs an action must enforce the application's trust rules inside its implementation.
-
-## Define the agent
-
-Now describe the agent's behavior and make the lookup available to it:
+Make the tool available to the agent and tell the model when to use it:
 
 ```ruby
 class CustomerSupportAgent < LittleGhost::Agent
   description "Answers customer support questions."
-  model "openai:gpt-5.6-luna"
+  model "openrouter:openai/gpt-5.6-luna"
   system_prompt <<~PROMPT
     Answer clearly and do not invent company guidance.
-    Use the help center lookup tool before stating company guidance.
+    Check the help center before stating company guidance.
   PROMPT
-
   tools HelpCenterLookupTool
 end
+
+run = CustomerSupportAgent.ask(
+  "I bought an item two weeks ago. Can I get a refund?"
+)
+
+run.response
+# One possible response:
+# Refunds are available within 30 days, so your purchase is eligible.
 ```
 
-An agent class is a reusable behavior definition. It owns its prompt, tools, model selection, limits, and other capabilities. This agent names an OpenAI connection and model directly, so the first example does not need a separate model profile.
+LittleGhost checks the model's arguments before it calls `HelpCenterLookupTool#call`. The schema checks shape, not permission. If a tool reads customer data or changes something, authorize that work from trusted application context. The tool's result then becomes context for the model.
+
+### Use trusted context for private data
 
-## Ask a question
+Model tool arguments are untrusted, even after their shape has been checked. Pass identity and permissions from your application's authentication boundary instead.
 
-Call the agent class to run one request to completion:
+While an Agent is working, LittleGhost binds each Tool instance to the current Run. The Tool can read trusted request values through its `run` accessor:
 
 ```ruby
-run = CustomerSupportAgent.ask(
-  "I bought an item two weeks ago. Can I get a refund?"
-)
+class OrderStatusTool < LittleGhost::Tool
+  ORDER_STATUSES = {
+    ["user-7", "account-2", "481"] => "out for delivery"
+  }.freeze
 
-if run.completed?
-  puts run.response
-else
-  warn "Support request ended as #{run.outcome}: #{run.error&.class}"
-end
-```
+  description "Look up an order that belongs to the current customer."
+  input_schema(
+    type: "object",
+    properties: {order_number: {type: "string"}},
+    required: ["order_number"],
+    additionalProperties: false
+  )
 
-`CustomerSupportAgent.ask` creates and consumes a `LittleGhost::Run`. A successful run exposes its final text through `#response`; it also retains the normalized result, outcome, usage, messages, and any terminal error.
+  def call(input)
+    lookup = [
+      run.invocation.actor_id,
+      run.invocation.context.fetch("account_id"),
+      input.fetch("order_number")
+    ]
+
+    ORDER_STATUSES.fetch(lookup) do
+      raise LittleGhost::ToolError, "Order not found"
+    end
+  end
+end
 
-The model can call `HelpCenterLookupTool` with `{"topic":"refunds"}` and answer along these lines:
+class CustomerSupportAgent < LittleGhost::Agent
+  tools HelpCenterLookupTool, OrderStatusTool
+end
 
-```text
-Refunds are available within 30 days, so a purchase from two weeks ago is eligible.
+run = CustomerSupportAgent.ask(
+  "Where is order 481?",
+  actor_id: "user-7",
+  context: {account_id: "account-2"}
+)
 ```
 
-Model wording and tool selection are not deterministic. The prompt directs the agent to ground company guidance in the validated lookup; applications that must enforce a lookup should put that ordering in a workflow.
+Here, `order_number` came from the model. The application supplied `actor_id` and `account_id` after authenticating the caller. LittleGhost places those request values on `run.invocation`; context keys become strings. The model cannot replace them through its tool arguments.
+
+That is enough to authorize the first Tool safely. [Core Concepts](core_concepts.md) names the request and working-state objects behind `run`, and [Running in Production](production.md) explains what changes when you add saved conversations.
 
 ## Stream the same agent
 
-Use `.stream_ask` when a console, HTTP response, or user interface should receive progress while the run is active:
+Use `.stream_ask` when a console, HTTP response, or user interface should receive progress as it happens:
 
 ```ruby
-CustomerSupportAgent.stream_ask("Can I get a refund?").each do |event|
+stream = CustomerSupportAgent.stream_ask("Can I get a refund?")
+
+run = stream.each do |event|
   case event.type
   when :text_delta
     print event.data.fetch(:text)
@@ -112,53 +166,30 @@ CustomerSupportAgent.stream_ask("Can I get a refund?").each do |event|
     warn event.data.fetch(:message)
   end
 end
-```
-
-The stream yields `LittleGhost::StreamEvent` objects. Text, tool activity, usage, traces, and terminal lifecycle facts share this interface, so callers do not need provider-specific response handling.
-
-Both calls use the same agent definition and active LittleGhost configuration. Core Concepts explains reusable runtimes when an application needs more control over shared services.
-
-## Add a model role when the application grows
-
-Direct targets keep a small application easy to read. A larger application can give the same selection a stable role, then change the underlying provider, model, and defaults without editing each agent class:
-
-```ruby
-LittleGhost.configure do |config|
-  config.providers = {
-    openai: {adapter: :openai, api_key: ENV.fetch("OPENAI_API_KEY")}
-  }
-  config.models = {
-    customer_support: {
-      target: "openai:gpt-5.6-luna",
-      settings: {temperature: 0.2}
-    }
-  }
-  config.default_model = :customer_support
-end
 
-class CustomerSupportAgent < LittleGhost::Agent
-  model :customer_support
-end
+puts "\n#{run.response}" if run.completed?
+warn run.error.class.name if run.failed?
 ```
 
-An agent may also keep a small amount of model-specific configuration beside its behavior:
+The stream yields `LittleGhost::StreamEvent` values. Text, tool activity, usage, and completion all look the same across providers. When enumeration finishes, `.each` returns the same `LittleGhost::Run` that now holds the final outcome and response.
 
-```ruby
-class DeliberateSupportAgent < LittleGhost::Agent
-  model(
-    provider: "openai",
-    model: "gpt-5.6-luna",
-    reasoning_effort: "high"
-  )
-end
-```
-
-Here, `provider` names a configured connection and every other key after `model` is a trusted model setting. Provider connections and model profiles may instead come from independent YAML files under `config/little_ghost`, or from paths selected in `LittleGhost.configure`. Inline declarations take precedence over explicit paths, which take precedence over conventional files; environment-based selection and the built-in default are the final fallback. `LittleGhost::Agent` and `LittleGhost::Configuration` document the complete shapes and precedence.
+## Give the code a home
 
-## Fit LittleGhost into your application
+LittleGhost does not require an application layout. Keep definitions beside related application code, or use these optional conventions:
 
-LittleGhost does not require an application layout. Keep agents and tools beside related application code when your framework or loader already has a home for them. If you want LittleGhost to eager-load these definitions, `app/agents` and `app/tools` are available conventions, and every lookup path is configurable.
+```text
+app/
+├── agents/
+│   └── customer_support_agent.rb
+├── assemblies/
+│   └── response_workflow.rb
+├── prompts/
+│   └── customer_support/
+│       └── system.erb
+└── tools/
+    └── help_center_lookup_tool.rb
+```
 
-Hosting remains the surrounding application's responsibility. A Rails controller, Rack endpoint, background job, CLI, or another Ruby entrypoint can call the same agent APIs shown above.
+You now have the smallest useful LittleGhost application: one Agent, one Tool, and one familiar Ruby call.
 
-Read [Core Concepts](core_concepts.md) next for model selection, reusable runtimes, subagents, workflows, sessions, and the boundaries between them. The API reference covers exact signatures for `LittleGhost::Agent`, `LittleGhost::Tool`, `LittleGhost::Configuration`, and `LittleGhost::Run`.
+When the feature grows, the calling style stays the same. An **assembly** lets one or more agents work as a unit while keeping `.ask` and `.stream_ask`. Read [Core Concepts](core_concepts.md) next and grow this Agent into a larger system.

data/docs/guides/production.md

@@ -0,0 +1,187 @@
+# Running in Production
+
+The Agent or Assembly you ran in a script can move into a controller, job, CLI, or service without changing shape. A long-running application usually adds stable model names, shared services, conversation history, background execution, and observability.
+
+## Select models by application role
+
+A direct target keeps a small definition self-contained:
+
+```ruby
+class CustomerSupportAgent < LittleGhost::Agent
+  model "openrouter:openai/gpt-5.6-luna"
+end
+```
+
+As an application grows, a **model role** gives that choice a stable application name:
+
+```ruby
+# config/initializers/little_ghost.rb
+LittleGhost.configure do |config|
+  config.providers = {
+    openrouter: {
+      adapter: :openrouter,
+      api_key: ENV.fetch("OPENROUTER_API_KEY")
+    }
+  }
+  config.models = {
+    customer_support: {
+      target: "openrouter:openai/gpt-5.6-luna",
+      settings: {temperature: 0.2}
+    }
+  }
+  config.default_model = :customer_support
+end
+
+class CustomerSupportAgent < LittleGhost::Agent
+  model :customer_support
+end
+```
+
+Provider connections and model roles can also live in YAML files under `config/little_ghost`, or in files you select explicitly. Values set in Ruby take priority. An explicitly selected file comes next, followed by conventional files and environment defaults. See `LittleGhost::Configuration` when you need every supported source and override.
+
+Prompts, caller input and history, tool results, and attachments may leave the application for the selected external provider. Select providers from trusted configuration and account for their retention and data-residency policies.
+
+## Configure once, call from anywhere
+
+The `LittleGhost.configure` block above is the entire initializer. Controllers and jobs can call your Agent and Assembly classes directly.
+
+Then call the Agent directly from a controller or job:
+
+```ruby
+class SupportQuestionsController < ApplicationController
+  def create
+    run = CustomerSupportAgent.ask(
+      params.require(:question),
+      actor_id: current_user.id,
+      context: {account_id: current_user.account_id}
+    )
+
+    if run.completed?
+      render json: {answer: run.response}
+    else
+      render json: {error: "Support request failed"}, status: :bad_gateway
+    end
+  end
+end
+```
+
+On the first class-level call, LittleGhost prepares model resolution, loading, prompt lookup, persistence, hooks, and factories. Later calls reuse those application services automatically.
+
+Each `.ask` creates a fresh top-level Run with fresh bound participants and Tools. Reusing application services does not create conversation history. Pass a stable `session_id` only when a later request should continue an earlier conversation.
+
+The controller supplies identity and account access from authenticated application state. The model cannot replace those values through its prompt or tool arguments. A background job uses the same direct calling style.
+
+Configure LittleGhost before the first Agent or Assembly call. Once application services start successfully, the configuration is locked so every request sees one stable setup.
+
+## Preserve conversation with Sessions
+
+A **Session** lets one request continue an earlier conversation. Pass the same session ID and trusted actor ID with each related call:
+
+```ruby
+run = CustomerSupportAgent.ask(
+  "What did we decide about my refund?",
+  session_id: "conversation-42",
+  actor_id: authenticated_user.id
+)
+```
+
+Take `actor_id` from authenticated application state. A session ID alone does not prove who the caller is, and a nil actor does not separate tenants. Built-in persistence drops system messages, temporary messages, and private reasoning. If you customize persistence, decide what else is safe to store.
+
+A session is checkpointed when its store write succeeds. The in-memory store lasts only as long as one process. Choose a durable `SessionStore` when conversations must survive a restart or continue on another process.
+
+{LittleGhost::SessionStores::Filesystem}[rdoc-ref:LittleGhost::SessionStores::Filesystem] is a built-in durable choice for a trusted local or shared filesystem. Set its root to the application-managed directory that holds session data:
+
+```ruby
+LittleGhost.configure do |config|
+  config.session_store = {
+    provider: LittleGhost::SessionStores::Filesystem,
+    root: "/var/lib/customer_support/sessions"
+  }
+end
+```
+
+Every Run has a session ID so LittleGhost can checkpoint its progress. If you do not supply one, LittleGhost generates a new ID for that call. Because your application does not reuse that generated ID, it does not create conversation continuity. A persistent SessionStore may still save working state under it before the Run finishes, so keep request context safe to store or filter sensitive fields in your store.
+
+## Stream or supervise long-running work
+
+`.stream_ask` runs on the caller's thread and yields `StreamEvent` values as the answer arrives:
+
+```ruby
+stream = CustomerSupportAgent.stream_ask(question)
+
+run = stream.each do |event|
+  publish(event) if event.type == :text_delta
+end
+
+record_outcome(run.outcome, error_type: run.error&.class&.name)
+```
+
+Use `start_execution` when the caller must stay free for other work, or when you want to deliver an interjection to an active response:
+
+```ruby
+execution = agent.start_execution(message: question) do |event|
+  event_buffer << event
+end
+
+execution.interject(message: "Include the latest ledger entry")
+execution.wait(deadline: Time.now + 30)
+execution.run.completed?
+```
+
+The event block runs on the worker thread, so keep it quick. Cancellation, deadlines, and `close` ask the work to stop; they cannot forcibly end arbitrary provider or tool code. They also cannot undo actions that already happened.
+
+## Treat tools as application boundaries
+
+A tool schema checks the shape of model-supplied input. Your application still owns permission checks, safe retries, rate limits, tenant boundaries, and auditing.
+
+Use the Tool binding's `run` to read current, application-established values from `run.invocation.context`. Do not make permission decisions from model arguments.
+
+Treat `RunContext#state` as mutable working and Session state. Revalidate anything restored from an earlier request. Synchronize access when parallel Tools share mutable state, or mark every Tool that reads or changes it as `exclusive true`.
+
+A `ToolError` message is visible to the model, so keep it safe to share. LittleGhost hides unexpected exception messages from model-facing results.
+
+When a step retries, its tool calls may happen again too. Prefer read-only work, idempotency keys, or operations that are safe to repeat.
+
+## Choose workspace and sandbox behavior explicitly
+
+A Workspace gives one Run a place for files. A Sandbox decides how filesystem and process operations happen there.
+
+`LittleGhost::UnrestrictedSandbox` uses the host machine with the Ruby process's permissions. It does not contain untrusted code. Expose only the tools the model needs, and use a real isolation boundary when untrusted code must run.
+
+The Run closes workspaces and sandboxes that LittleGhost creates for it. If your application passes an existing instance instead, your application keeps ownership and must close it when its own lifecycle ends.
+
+## Instrument without leaking the application
+
+LittleGhost emits events as a request starts, calls a model or tool, moves between assembly steps, retries, and finishes. Instrumentation subscribers and OpenTelemetry exporters can send those events to your monitoring system.
+
+An external telemetry service may receive application identifiers and event data. Redact sensitive values before they leave your boundary. Avoid attributes with many unique values, such as raw order or request IDs. Replacing one identifier does not make the rest of the data anonymous.
+
+A composite `RunResult` includes short step summaries and trajectory queries. Keep detailed provider errors and sensitive diagnostics in trusted monitoring channels, not in model or user responses.
+
+## Keep ownership and failure visible
+
+One top-level Run owns the workspace and sandbox that LittleGhost creates for it, plus application resources registered with `run.register`. It closes those resources after success, failure, a partial response, or cancellation. Existing workspace or sandbox instances passed by the application remain caller-owned.
+
+Ordinary execution failures appear on the Run and its final event. Cleanup, event delivery, or instrumentation can still raise an exception: once those boundaries fail, LittleGhost cannot promise a clean ending.
+
+## Advanced: work with Runtime directly
+
+A Runtime is the internal home for shared model resolution, loading, persistence, hooks, and resource factories. Most applications never need to handle it: `LittleGhost.configure` and class-level `.ask` are enough.
+
+Use `LittleGhost.runtime` when an extension needs the shared object itself. Construct a separate Runtime only when one process deliberately hosts an isolated LittleGhost setup:
+
+```ruby
+configuration = LittleGhost::Configuration.new(root: isolated_root)
+runtime = LittleGhost::Runtime.new(configuration: configuration)
+agent = CustomerSupportAgent.new(runtime: runtime)
+```
+
+An explicit Runtime is an independent configuration snapshot. It does not replace LittleGhost's shared default.
+
+One Runtime can serve independent calls from several threads. Each call gets its own Run, participants, Tools, and Runtime-created workspace and sandbox. An Agent or Assembly already bound to an active Run must stay with that Run.
+
+Within one SessionStore instance, LittleGhost serializes calls sharing a Session. Multi-process deployments need coordination from their store. Custom stores, identity and credential resolvers, model resolvers, hooks, instrumentation subscribers, providers, and resource factories may receive concurrent calls and must be thread-safe.
+
+Runtime has no shutdown step. Shared services supplied by the application keep their own lifecycle. Shut those services down with the rest of your application. If you installed process-wide instrumentation subscribers, flush or shut down `LittleGhost::Instrumentation` during application shutdown.
+
+For exact constructors, options, events, extension contracts, and error behavior, continue into the API reference for `LittleGhost::Configuration`, `LittleGhost::Runtime`, `LittleGhost::Run`, `LittleGhost::Execution`, `LittleGhost::Session`, `LittleGhost::Tool`, and `LittleGhost::StreamEvent`.

data/docs/guides/prompt_views.md

@@ -0,0 +1,132 @@
+# Prompts as Views
+
+A short prompt fits nicely inside an Agent class. As the instructions grow, move them into a **prompt view**: an ERB file that LittleGhost finds and renders for the Agent.
+
+This keeps the Agent easy to scan. It also gives shared instructions and application values a natural home.
+
+## Start with the inline prompt
+
+The Agent from Getting Started keeps its first instruction close to the model:
+
+```ruby
+class CustomerSupportAgent < LittleGhost::Agent
+  model "openrouter:openai/gpt-5.6-luna"
+  system_prompt "Answer customer questions clearly and concisely."
+end
+```
+
+Inline prompts are a good fit while the whole instruction is one thought.
+
+## Move a growing prompt into a view
+
+Remove `system_prompt` from the class:
+
+```ruby
+class CustomerSupportAgent < LittleGhost::Agent
+  model "openrouter:openai/gpt-5.6-luna"
+  tools HelpCenterLookupTool, OrderStatusTool
+end
+```
+
+Then create `app/prompts/customer_support/system.erb`:
+
+```erb
+You help customers understand their orders and account.
+
+Answer clearly and concisely.
+Never invent company guidance. Check the help center when policy matters.
+Use the order status tool before making a claim about a private order.
+```
+
+That is enough. `CustomerSupportAgent` becomes `customer_support`, so LittleGhost looks for `customer_support/system.erb` under `app/prompts`.
+
+The prompt is still a system instruction sent to the selected model provider. Keeping it in a view improves organization; it does not keep the content inside your process.
+
+## Give the view application values
+
+Use `prompt_local` for a value the application owns:
+
+```ruby
+class CustomerSupportAgent < LittleGhost::Agent
+  prompt_local :company_name, "Northstar"
+end
+```
+
+The local is available by name in the view:
+
+```erb
+You are a customer support agent for <%= company_name %>.
+Answer clearly and concisely.
+```
+
+A block can resolve a trusted value for each Agent instance. Add it to the Agent class too:
+
+```ruby
+class CustomerSupportAgent < LittleGhost::Agent
+  prompt_local(:policy_version) { SupportPolicy.current_version }
+end
+```
+
+Prompt views also receive `invocation`, `run`, and `agent`. Reach for those when the instruction truly depends on the current request. Keep user wording in the caller message unless you deliberately want it inside the system instruction.
+
+Every rendered value may be sent to the model provider. Pass only data that belongs in the prompt.
+
+## Share a small partial
+
+Partials keep repeated instructions in one place. Create `app/prompts/shared/_voice.erb`:
+
+```erb
+Use a warm, direct voice for <%= company_name %>.
+Prefer one clear next step over a long list of possibilities.
+```
+
+Render it from the Agent's system view:
+
+```erb
+You are a customer support agent for <%= company_name %>.
+
+<%= partial "shared/voice", locals: {company_name: company_name} %>
+```
+
+The underscore marks a partial. Its locals are explicit, so it does not quietly inherit everything available to the parent view.
+
+## Override the convention when it helps
+
+Most named Agents can rely on their conventional path. Use `system_template` when a class should read a differently named view:
+
+```ruby
+class BillingSupportAgent < LittleGhost::Agent
+  system_template "customer_support/billing"
+end
+```
+
+LittleGhost chooses one prompt source in this order:
+
+1. An inline `system_prompt`
+2. An explicit `system_template`
+3. The Agent's conventional `system.erb` view
+
+Applications can add prompt lookup roots through `Configuration#prompt_paths`. Earlier roots win, which is useful when one trusted application layer overrides a shared prompt package.
+
+## Treat views as application code
+
+Prompt views run as ERB inside the Ruby process. They can call Ruby, so keep every prompt directory application-controlled and non-user-writable. Never turn a request or model-supplied path into a prompt root.
+
+`TrustedPath` exists for the uncommon case where trusted application code selects a request-specific root. It records a trust decision; it does not make an untrusted directory safe.
+
+## Keep request composition separate
+
+A prompt view defines reusable instructions for one Agent. A Workflow may still build request-specific input for that Agent:
+
+```ruby
+invoke CustomerSupportAgent, input: <<~MESSAGE
+  #{input.text}
+
+  Verified research:
+  #{research}
+MESSAGE
+```
+
+The Workflow is composing this request. `CustomerSupportAgent` still receives its own system prompt view when it runs.
+
+Continue with [Running in Production](production.md) to configure model roles, preserve sessions, supervise execution, and connect observability.

data/lib/little_ghost/ag_ui/adapter.rb

@@ -142,10 +142,10 @@ module LittleGhost
                 "little_ghost.model_retry",
                 source.data.merge(superseded_message_id:).compact
               )
-            when :agent_interrupt_delivered
+            when :agent_interjection_delivered
               output << custom(
-                "little_ghost.agent_interrupt_delivered",
-                source.data.slice(:interruption_ids, :batch_key).compact
+                "little_ghost.agent_interjection_delivered",
+                source.data.slice(:interjection_ids, :batch_key).compact
               )
             when :subagent
               output << custom("little_ghost.subagent", source.data.fetch(:event, source.data))