Memory, Swarms & Self-Dev with Jcode

Jcode's three headline capabilities — durable memory, agent swarms, and self-dev mode — are what separate it from minimal harnesses like pi. This tutorial walks through each with real workflows.

Durable Memory

Jcode embeds each turn and response as a semantic vector. Every turn queries a graph of memories to find related entries via cosine similarity, then injects the hits into the conversation — no explicit memory tool calls, no burned tokens on recall.

Enable and verify

jcode
/memory      # toggle the memory feature

An optional memory sideagent does deeper retrieval and relevance verification before injection. Enable it in config.toml:

[features]
memory = true

[agents]
memory_sidecar = true

Workflow: cross-session continuity

1. In session A, resolve an architectural decision (e.g., "use TTL-based cache invalidation in billing").
2. Days later in session B, ask jcode to implement a similar pattern in a new endpoint.
3. Jcode recalls the earlier decision from memory and applies the same convention — even flagging where the current code diverges.

Because memories are injected automatically on semantic match, you never re-explain established decisions. Keep project decisions explicit and consistent in your prompts so they become retrievable memories.

Agent Swarms

Swarms coordinate multiple agents on independent or interacting work, with model routing and file-conflict detection.

Enable and configure

[features]
swarm = true

[agents]
spawn_mode = "auto"      # auto-spawn on complex tasks, or "manual"
concurrency_cap = 8      # max parallel agents

Swarm policy lives in .jcode/swarm-prompt.md (project) or ~/.jcode/swarm-prompt.md (global) — it defines model routing and structure for spawned agents.

Workflow: parallel feature build

Refactor these four modules into independent tasks:
- src/auth → task 1
- src/billing → task 2
- src/notifications → task 3
- src/search → task 4
Each: extract pure logic into lib/, keep public API identical,
run the module's tests. Report each task's results separately.

Jcode detects when a swarm member changes a file another agent already read and notifies the affected agent — no silent stale reads. Use Alt+N in the TUI to focus the inline swarm panel and watch the swarm live.

Background Tasks

Start any long-running command with run_in_background and it becomes a task the agent can list, tail, inspect, cancel, or wait on:

• The wait action blocks until the task finishes or hits a progress checkpoint — the agent wakes on events instead of burning turns on sleep loops.
• A foreground command that outruns its timeout is adopted into the background and survives even a reload of jcode's own binary.
• Output is parsed for progress and rendered as a live card in the TUI: percent, counts like 6/10 tests, byte ratios, ETA (from JCODE_PROGRESS lines or inferred from ordinary output).

An agent can run a dozen tasks at once and let the daemon wake it when one needs attention.

Self-Dev Mode

Jcode's most unusual capability: tell it to enter self-dev mode and it starts modifying its own source code.

/selfdev

Self-dev sessions:

1. Read jcode's Rust source (it's MIT and optimized to be self-editable).
2. Make the change you asked for (a new tool, a keybinding, a TUI behavior).
3. Build and run the test suite.
4. Reload its own binary and continue work in your (potentially many) sessions — fully automatically.

This is how jcode's own system prompt shrank from 2,476 tokens (v0.1) to 659 tokens (v0.44) — it optimized itself. Self-dev is a practical template for "dogfood your agent on its own codebase" that you can apply to any project with good tests and a fast build.

Headless Runs

jcode run keeps iterating on a task across turns until the work is finished — auto-poke checks the todo list at every turn end and pushes the model back to work when todos are incomplete:

jcode run "Audit src/ for N+1 queries. Add todos for each issue found,
then fix them and run the test suite until green."

Sessions survive disconnects: if the connection drops mid-turn, the daemon keeps executing and jcode --resume picks the session back up.

Common Pitfalls

• Memory without structure — inconsistent phrasing yields weak embeddings. Keep project decisions stated the same way across sessions.
• Swarm conflicts — cap concurrency_cap if agents touch overlapping files; the conflict detector helps but doesn't merge work.
• Self-dev without tests — self-dev only lands cleanly if the suite catches regressions. Build tests first.
• Unbounded background tasks — use progress checkpoints so the agent wakes on events rather than blocking indefinitely.

Related Pages

• Jcode Getting Started — Installation and provider setup
• Prompt Engineering in Jcode — hill-climbable goals, confidence stepping, todo discipline
• Jcode Configuration Reference — config.toml, MCP, memory, remote gateway
• Agent Memory Architectures (Agents Section) — memory design patterns
• Multi-Agent Collaboration (Agents Section) — coordination patterns