Skip to content

Instantly share code, notes, and snippets.

@jfarcand

jfarcand/atmosphere-personal-agent-strategy.md Secret

Created April 14, 2026 18:22
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save jfarcand/e6d05b71f49386422d06a955e089728b to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save jfarcand/e6d05b71f49386422d06a955e089728b to your computer and use it in GitHub Desktop.
Download ZIP
Atmosphere — Personal Agent Platform Strategy (working draft, private)
Raw
atmosphere-personal-agent-strategy.md

Atmosphere — Personal Agent Platform Strategy

Working draft. Secret gist. Not public. Iterated in conversation with ChefFamille.

Date: 2026-04-14 Status: v0.1 — strategy anchor, not a roadmap commitment

Thesis

Atmosphere is the Java platform layer for personal agents. You pick your framework (Spring AI, LangChain4j, Google ADK, Koog, Semantic Kernel, Embabel, or the Built-in runtime), write a skill file, and inherit memory, identity, multi-channel continuity, auditable permissions, MCP/A2A/AG-UI endpoints, and durable streaming — regardless of which runtime you picked.

You don't pick Atmosphere instead of your framework. You pick Atmosphere on top of it.

That sentence is the feature filter for everything that follows. If a feature only helps one runtime, runtime code owns it. If a feature should help all seven equally, Atmosphere owns it.

What "personal agent" means here

Two definitions, both in scope:

  1. Long-lived, one user, remembers you. The Claude Code / ChatGPT memory model. Agent follows the user across sessions, channels, devices. Identity is stable. Memory is persistent and user-inspectable.

  2. User-owned, host-portable. The OpenClaw / gitagent model. The agent definition is a versioned artifact the user owns, not a service they rent. Portable across hosts and across runtimes.

Personal-agent features that serve both definitions are prioritized. Features that serve only one are deprioritized.

What to learn from (and what to explicitly skip)

Five references cover the entire personal-agent surface in 2026. Study these, skip the rest.

Study

  • Claude Code Agent SDK — the personal-agent reference implementation. Hierarchical CLAUDE.md memory, skills, hooks, permission modes, auto-memory, MCP personal servers. Key lesson: UX of trust. The user sees what the agent remembers and can edit it. Memory is a user-facing surface, not a backend data store.

  • OpenAI Agents SDK (Python) — production primitives for long-running sessions. Handoff, compaction-aware sessions, guardrails. Key lesson: how to stay robust across many turns and partial failures.

  • Anthropic memory tool + ChatGPT memory — not a framework, a product pattern. User opens Settings, sees "things this agent remembers about you". Key lesson: ship the UI alongside the SPI. Memory without inspection is a GDPR problem waiting to happen.

  • OpenClaw / gitagent — agent identity as a versioned, portable artifact. Key lesson: portability is a product feature, not a technical property. "My agent travels with me" is the sales pitch.

  • LangGraph — durable execution primitives (interrupt, resume, checkpoint, fork). Atmosphere already has CheckpointStore with fork semantics. Key lesson: expose it as a user-facing "pause and resume my agent" feature, not just plumbing.

Skip

  • CrewAI — we have @Coordinator / AgentFleet, no second DSL.
  • Smolagents — code execution is a tool concern, not a platform concern.
  • Vercel AI SDK — frontend-specific, not a backend platform differentiator.
  • The seven hosted runtimes as references — we host them. We learn from them by running contract tests across them, not by copying their APIs.

What to build — six themes

Each theme passes the runtime-agnostic filter: shipping it once makes every hosted runtime inherit it for free.

Theme 1 — Runtime-agnostic persistent personal memory (flagship)

Why first: every Java framework today makes you build memory yourself. The Atmosphere pieces exist (LongTermMemory, SemanticRecallInterceptor, PersistentConversationMemory, EmbeddingRuntime) but don't tell a single story. This is the single biggest unlock because shipping it once makes every hosted runtime inherit it.

What to build:

  • Unified PersonalMemory facade combining conversation history, semantic facts, working memory, hierarchical rules — one SPI.
  • SQLite and Redis backends shared across all seven runtimes.
  • Auto-memory: agent writes memory during conversation, Claude Code style.
  • GET /atmosphere/agent/{name}/memory/{userId} inspection endpoint — redacted, human-readable.
  • Edit / delete endpoints for user-facing UI. GDPR and trust both require this.
  • Retention policies declared in the skill file.

Contract test: every one of the seven runtimes must pass a conformance test that writes a fact, restarts the agent, and reads the fact back.

Theme 2 — Portable personal agent manifest

Why second: cheap to ship, massive narrative payoff, entry point for the gitagent / OpenClaw crowd.

What to build:

  • agent.atmosphere.yaml (or whatever we call it) bundling identity (name, tone, rules, skill file ref), memory retention, permission mode, channel bindings, skill overrides, MCP personal servers, per-user secret refs.
  • Versionable, exportable, importable, host-agnostic.
  • Loader that wires a @Agent equivalent at runtime from the manifest.
  • Round-trip test: export from Spring AI, import on LangChain4j, agent behaves identically.
  • Adapter that reads gitagent / OpenClaw format and emits ours.

The pitch: "your personal agent travels with you. Switch from Spring AI to Koog, your agent is unchanged."

Theme 3 — Multi-channel continuity (the flagship sample)

Why third: the feature is already there, the proof point isn't. This sample is the headline image for everything else.

What to build:

  • One agent, three channels (Slack + web + mobile), one user ID, one conversation thread.
  • User starts in Slack, picks up on web, finishes on mobile. Memory and state follow them.
  • Pure packaging + narrative work — the underlying primitives (durable sessions, channels, persistent memory) already exist.

Why it matters: today samples show per-channel agents. Nobody demonstrates that Atmosphere's real differentiation is continuity across channels. Until there's a sample users can run, the feature doesn't exist in users' minds.

Theme 4 — Session permission modes + per-user audit log

Why fourth: trust is the feature that converts "AI is scary" into "AI is my assistant".

What to build:

  • PermissionMode enum (DEFAULT, PLAN, ACCEPT_EDITS, BYPASS, DENY_ALL) on the durable session. Layers over existing per-tool @RequiresApproval.
  • Per-user audit endpoint: "what has this agent done on my behalf?" Derived from CoordinationJournal + tool execution history. The data exists; the endpoint doesn't.
  • Plan mode: agent generates a plan, user approves before execution. Claude Code parity on the highest-leverage permission mode.

Theme 5 — Per-user MCP personal servers

Why fifth: this is the extension point that makes personal agents actually personal, and no Java framework offers it today.

What to build:

  • Per-user MCP client configuration. User brings their own tools: GitHub with their token, Gmail with their creds, filesystem with their paths.
  • Atmosphere already hosts an MCP server; the gap is letting users configure which MCP servers their agent can call.
  • Tools consult per-user MCP configuration at runtime.
  • UI/API for user to install / uninstall / authorize MCP tools.

Theme 6 — Skill polish for Claude Code parity

Why last: individually small, collectively closes the most visible parity gap.

What to build:

  • $ARGUMENTS and {{var}} substitution in skill files.
  • Path / context scoping — skill X only applies in context Y (directory, channel, user group).
  • Per-user skill overrides layered on top of the curated registry.
  • skill inspect command showing resolved state.

Sequencing — 90 days, staged for narrative build-up

  • Month 1: Themes 1 + 2. Memory and manifest unlock everything else and give us the headline ("write once, runs on seven runtimes").
  • Month 2: Themes 3 + 4. Flagship continuity sample + trust / audit story.
  • Month 3: Themes 5 + 6. Personal MCP + skill polish closes Claude Code parity on the features that matter.

Each month ships a sample and a short post. Not a launch — visible progress under the radar.

Six months from now, if all six themes ship and hold together, then there's a story worth telling publicly. Until then, we build.

Non-goals (the explicit no's that protect focus)

  • No graph workflow DSL. Atmosphere's seven runtimes have their own orchestration primitives. LangGraph owns the category. We have @Coordinator / AgentFleet; we don't need another DSL.
  • No voice / realtime pipeline. Too much investment for a feature that isn't personal-agent core. Revisit in a year once the base is solid.
  • No code execution sandbox. Tool concern, not platform concern. Users bring their own.
  • No new LLM client abstraction. Our clients are the seven runtimes.
  • No feature-parity chasing with Python / TS frameworks on anything that doesn't pass the runtime-agnostic filter.

Success measure — six yes/no questions, six months out

  1. Can I build a personal agent on Spring AI, export it as atmosphere.yaml, import it on LangChain4j, and it keeps memory + identity?
  2. Can my user see what their agent remembers about them and edit it?
  3. Can my user start a conversation in Slack, pick it up on web, and the agent doesn't forget?
  4. Can my user bring their own MCP tools (GitHub, Gmail, filesystem) without touching my agent code?
  5. Can I audit everything an agent has done on behalf of a specific user?
  6. Does switching from Spring AI to ADK to Koog require zero personal-agent code changes?

All six yes → Atmosphere has found its shape. Any no → we know what to build next.

Contract tests enforce each answer in CI so we can't drift. Same philosophy as AbstractAgentRuntimeContractTest.expectedCapabilities().

Key success factors while under the radar

  • Contract-tested guarantees over marketing claims. If we say "runs on all seven runtimes", we prove it in CI per-feature. No v2-gist-style superlatives. Ever.
  • Flagship samples, not feature lists. People discover frameworks through samples. Each theme ships with one.
  • One post per month, not one per week. Quality narrative compounds; noise doesn't.
  • Refuse the framework war. When people compare us to LangGraph or CrewAI, the answer is always "Atmosphere hosts your LangChain4j / Spring AI agents" and we move on. We're not a competitor to those frameworks — we're their platform.
  • Own the Java narrative. No Python envy, no TypeScript envy. The pitch is virtual threads, MCP / A2A / AG-UI convergence, and fifteen years of async / real-time heritage. The enterprise Java crowd is under-served on personal agents and that's our audience.
  • Recruit the Claude-Code-pilled, not the LangGraph-pilled. The users who want "Claude Code for my Spring Boot shop" are our audience. The ones who want a workflow DSL in Java aren't — send them to Temporal and move on.

Open questions (for the continued brainstorm)

  • Memory schema: unified SPI or federation over existing LongTermMemory / PersistentConversationMemory / SemanticRecallInterceptor? Greenfield is cleaner; federation is cheaper.
  • Manifest format: new spec or adopt gitagent / OpenClaw directly and extend? Adoption is faster; new spec fits Atmosphere's shape better.
  • Auto-memory trigger: every turn, every N turns, or LLM-decided via tool call? Each has different failure modes.
  • Plan mode UX: blocking approval modal or async email-style approval? Depends on channel.
  • Per-user MCP trust model: who verifies the user's MCP tokens? Atmosphere, the user, or OAuth-style delegation?
  • Under-the-radar pace: six months in private, or start teasing at month 3 with the continuity sample? Balance between stealth and recruiting early adopters who give real feedback.
  • Which sample becomes the flagship: dentist-agent, expo-classroom, or a net-new "personal assistant" sample built for this strategy? Net-new is clearest but costs more.

Status log

  • 2026-04-14 — v0.1 drafted after refocusing from the (abandoned) competitive gap analysis gist. Thesis locked. Themes and non-goals agreed in principle. Next: work open questions and start Theme 1 scope audit.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment