Overview

In AfferLab, strategies run inside isolated worker threads.

Inside that worker, the platform provides a single runtime object called ctx.

ctx is the strategy-facing API used to:

• read the current turn input
• access conversation history
• construct prompts
• call the active model
• persist strategy state
• interact with memory
• communicate results back to the host

Strategies never interact directly with the host runtime. All interaction happens through ctx.

Why ctx Exists

Strategy code does not directly access:

• the SQLite database
• model provider clients
• Electron APIs
• renderer state

Instead, the host exposes a safe runtime interface inside the worker.

That interface is ctx.

This keeps strategies:

• deterministic
• sandboxed
• provider-agnostic

What ctx Includes

The current runtime context includes:

• ctx.input
• ctx.history
• ctx.message
• ctx.config
• ctx.budget
• ctx.capabilities
• ctx.slots
• ctx.llm
• ctx.state
• ctx.memory
• ctx.utils

Each section is documented in its own page.

Typical Usage

Example:

export default defineStrategy({
  onContextBuild(ctx) {
    const history = ctx.history.recent(10)

    ctx.slots.add(
      'system',
      { role: 'system', content: 'You are a helpful assistant.' },
      { priority: 3, position: 0 }
    )

    if (history.length) {
      ctx.slots.add(
        'history',
        history,
        { priority: 1, position: 1, trimBehavior: 'message' }
      )
    }

    ctx.slots.add(
      'input',
      ctx.input,
      { priority: 2, position: 2 }
    )

    return ctx.slots.render()
  }
})

In this pattern:

• ctx.history provides previous messages
• ctx.input represents the current user turn
• ctx.slots builds the prompt structure
• ctx.slots.render() returns the final prompt

What ctx Does Not Do

ctx is not a direct database handle or provider SDK wrapper.

Strategies should never:

• query the database directly
• upload files manually
• call model provider APIs

These responsibilities are handled by the AfferLab host runtime.

Strategies only describe how the prompt should be constructed and how host-backed APIs should be used.

The host is responsible for:

• executing model requests
• handling provider file APIs
• managing memory and assets
• enforcing token budgets

This separation keeps strategies portable and provider-agnostic.