Intelligence Pipeline

Myco runs an intelligence pipeline in the background that reads your captured sessions, extracts observations into the knowledge vault, links them to their sessions, and keeps digest extracts fresh. It’s fully automatic — once providers are configured, you don’t need to trigger it manually. This page covers what it does, what tasks are available, how to configure providers, and how to schedule or disable parts of it.

What the pipeline produces

• Spores — discrete observations extracted from session activity (gotchas, decisions, discoveries, trade-offs, bug fixes, and higher-order wisdom syntheses)
• Lineage — spores stay linked to the sessions and plans they came from, so every observation is traceable to its source
• Session titles and summaries — human-readable labels for every captured session, generated from the actual work done
• Digest extracts — pre-computed project context at three depth tiers (1500 / 5000 / 10000 tokens) that get injected at session start
• Skill candidates — procedural patterns worth turning into skills (requires approval)

Every piece of this comes from the same source material: the prompts, tool calls, and assistant summaries captured by the symbiont hooks. Nothing is invented; everything traces back to a session.

Tasks

Fourteen tasks cover the full lifecycle. Most users only interact with vault-evolve (the default scheduled task) or vault-seed (a one-shot for brownfield repos) — the others are available for manual trigger or specialized workflows.

Intelligence

vault-seed is safe to re-run. It checks the vault first and, if a prior seeding pass already populated it, exits after a brief check instead of creating duplicate spores — so re-triggering it by accident (or running it again after a partial failure) costs a few cents rather than a full pass. A full pass over a mid-sized codebase runs a few dollars and several minutes; the re-seed check itself completes in seconds.

Cortex injection

Canopy

See Canopy for what these produce.

Skill lifecycle

See the Skills docs for the full skill lifecycle.

Configuring providers

Every task can use a different LLM provider. Configuration is all in myco.yaml under the agent: key, with a precedence hierarchy from global defaults to per-phase overrides.

The simplest setup

One provider for everything:

agent:
  provider:
    type: anthropic
    model: claude-sonnet-4-6

That’s it. Every task will use Claude Sonnet via the Anthropic API. See Authentication for the one-time credential setup background runs need.

Authentication (anthropic)

Background runs spawn the Claude Code CLI in an isolated session directory ($MYCO_HOME/agent-sessions) so agent transcripts never mix with your own sessions. The CLI scopes login state to that directory — your interactive claude login does not carry over. Provision a headless credential once per machine:

claude setup-token   # prints a long-lived token (Pro/Max subscription auth)

Then paste the token under Settings → Myco Agent → Claude subscription (Connect). Headless alternative: add it to $MYCO_HOME/secrets.env (~/.myco/secrets.env by default) yourself:

CLAUDE_CODE_OAUTH_TOKEN=sk-ant-oat01-...

The daemon loads secrets.env into the environment and passes the token to every Anthropic-provider run; local-provider runs deliberately never see it. myco doctor verifies this under the Intelligence check; a run that fails to authenticate reports the same remediation in its error and raises a notification that deep-links to the Settings card.

One wrinkle to know: a token saved through Settings takes effect immediately, but if you later HAND-edit secrets.env for a key the UI has previously written, restart the daemon — the layered-secrets loader protects externally-set env values from file overrides.

Per-task overrides

A common pattern is using a fast local model for lightweight tasks (title generation) and a capable cloud model for the heavy work:

agent:
  provider:                          # Global default
    type: anthropic
    model: claude-sonnet-4-6
  tasks:
    title-summary:
      provider:                      # Local model for titles
        type: ollama
        model: granite4:small-h
        context_length: 32768

Supported providers

For local providers, set a context_length that matches the model’s capabilities — Myco uses it to configure the runtime correctly.

Per-phase overrides (advanced)

For phased tasks like vault-evolve, you can override the provider for individual phases. Useful for mixing cloud quality and local cost:

agent:
  tasks:
    vault-evolve:
      phases:
        extract:
          provider:
            type: anthropic           # Quality for extraction
            model: claude-sonnet-4-6
        consolidate:
          provider:
            type: ollama              # Local for consolidation
            model: llama3.2

Scheduling

Each task runs on its own schedule. The defaults ship with the built-in task definitions; you override them in myco.yaml.

agent:
  scheduled_tasks_enabled: true      # Master switch for all scheduled tasks
  event_tasks_enabled: true          # Master switch for event-driven tasks (title-summary)
  tasks:
    vault-evolve:
      schedule:
        enabled: true
        intervalSeconds: 300         # Check for unprocessed batches every 5 min
    skill-survey:
      schedule:
        enabled: true
        intervalSeconds: 600         # Every 10 min when candidates might exist

For capture-only projects, leave the project capability toggles off. Myco still captures sessions and keeps search available, while heavier intelligence work such as Vault Evolution, Canopy mapping, and skill lifecycle tasks stays off. Canopy context injection follows the Canopy capability for each project. See Grove Management for the user-facing guide to project capabilities.

Tasks only run when Myco is active or recently active. Background work pauses when the developer has stepped away.

Triggering tasks manually

From the dashboard’s Operations page you can kick off any task on demand — useful for catching up after a gap, re-running after a provider change, or testing a new task configuration.

From the CLI:

myco task run vault-evolve       # Run the default pipeline now
myco task run skill-survey       # Survey for new skill candidates

myco agent --task <name> is the equivalent lower-level form. Use myco task run <name> when you want the task-oriented CLI surface, including --dry-run.

Custom tasks

Drop a YAML task definition into .myco/tasks/*.yaml and it’ll load alongside the built-ins on restart. Custom tasks have access to the same tool set and scheduling options as built-ins. The built-in task definitions are in packages/myco/src/agent/definitions/tasks/ if you want reference examples.

Example one-shot recipe: docs/examples/skill-decontaminate.yaml cleans up older generated skills whose live procedural prose contains point-in-time release, PR, date, session, or decision-state artifacts.

Monitoring and troubleshooting

The dashboard’s Logs page gives you real-time filtered output if you’d rather read it in the UI. Agent run details (which phases ran, what they produced) live on the Operations page.