Mervin Praison

Claude Tag is Anthropic’s new team-facing product: an always-on @Claude teammate inside Slack that reads channel context, delegates multi-step work asynchronously, learns from conversations over time, and can proactively surface updates — launching in beta on 23 June 2026 for Claude Enterprise and Team customers on Opus 4.8.

%%{init: {"theme": "base", "themeVariables": {"background": "transparent", "lineColor": "#000000"}}}%%
graph TD
    A[Team member tags @Claude] --> B[Slack channel session]
    B --> C[Agent identity + Access bundle]
    C --> D[Sandbox on Anthropic infra]
    D --> E[Agent Proxy]
    E --> F[GitHub / warehouse / APIs]
    F --> G[Results in thread]
    B --> H[Channel memory]
    B --> I[Routines / ambient mode]
    I --> J[Scheduled + proactive updates]
    K[Admin console] --> C
    K --> L[Spend limits + audit log]

    classDef agent fill:#8B0000,color:#fff
    classDef hook fill:#189AB4,color:#fff
    classDef decision fill:#444,color:#fff

    class A agent
    class D agent
    class G agent
    class E hook
    class C decision
    class K hook

What Claude Tag is

Anthropic positions Claude Tag as the next evolution of Claude Code — not a new foundation model, but a workflow layer that makes Claude multiplayer, proactive, and persistent inside the tools teams already use. You grant Claude access to selected Slack channels, connect tools/data/codebases, then anyone in the channel can tag @Claude with a task and move on while it works in the thread.

Internally at Anthropic, tagging @Claude is now a primary way work gets done: 65% of the product team’s code is created via their internal Claude Tag deployment. The same pattern is spreading beyond engineering — chasing product metrics, triaging support tickets, and debugging production issues.

Official docs example: a teammate tags Claude to investigate slow checkout; it posts done/in-progress steps in-thread — pulling metrics, diffing deploys, reproducing queries, opening a fix PR.

Four design shifts vs solo chat

Claude Tag shifts AI from a private back-and-forth to a visible teammate in the channel where decisions already happen.

How a task runs end-to-end

Tag @Claude with a request in plain language. Claude breaks work into stages, posts a checklist as it progresses, uses connected tools, and returns results in the Slack thread. If you’ve used Claude Code or Cowork, the interaction pattern feels familiar — but the session is scoped to the channel’s agent identity, not your personal account.

@Claude checkout has felt slow all morning — compare latency against this morning's deploy and find what's causing it.

Typical in-thread progress:

• Done: Pulled p99 latency from Datadog
• Done: Diffed deploy 4f2c1 against main
• Done: Reproduced the slow query locally
• In progress: Opening a pull request with the fix…

Delegation is asynchronous by design: set a task, focus on other priorities, and follow progress in the shared thread.

Agent identity: Claude acts as itself

The core security innovation is agent identity — Claude Tag does not “act as the user.” In shared channels, Claude uses service accounts provisioned by admins: the Claude Slack app, the Claude GitHub App, warehouse credentials, and so on. Work is attributed to those accounts, auditable in each system’s logs, and bounded by per-channel Access bundles.

Admins scope what the agent can reach per channel; Claude never becomes a side door into someone’s private documents.

Agent Proxy architecture

Work runs in an isolated sandbox on Anthropic infrastructure. When Claude needs external systems, requests cross Agent Proxy — credentials stay in a store and are injected at the network boundary; the model and sandbox never receive raw keys. Default policy is deny: hosts are blocked unless explicitly allowed.

Channel vs DM behaviour

Private channels get distinct identities; public channels share workspace-level identity. Memory from public channels is workspace-shared; private channel memory stays isolated. Admins can disable DMs org-wide.

Proactive routines and ambient mode

Beyond on-demand tagging, Claude Tag supports routines — standing instructions that run on schedules or triggers:

@Claude every weekday at 9am Pacific, read open threads here, check linked tickets and PRs, and post one-line status per item.

@Claude watch #product-announce and #eng-announce. Once a day, post here if anything is relevant to user education.

@Claude subscribe to PR #482 in acme/data-pipeline. When CI finishes or a review lands, post here and tag me if anything failed.

With ambient behaviour enabled, Claude proactively flags cross-channel information, follows unresolved threads, and tags humans when a decision is needed — without waiting for a mention.

Channel memory

Memory belongs to the channel, not individual users. Claude accumulates facts from work sessions and explicit instructions like @Claude remember for this channel: …. Public-channel memory is readable workspace-wide; private-channel memory stays scoped. Admins can view/edit memory files at claude.ai/admin-settings/claude-tag.

Use cases Anthropic highlights

Admin setup (four steps)

Owners configure Claude Tag at claude.ai/admin-settings/claude-tag. Installing the Slack app is a prerequisite — setup means provisioning an identity.

1. Pair Slack workspace — install Claude for Slack, send @Claude connect (Slack admin only), paste 15-minute pairing code
2. Give Claude access — create an Access bundle with service-account credentials (not personal logins); GitHub via Claude GitHub App separately
3. Set spending limit — org monthly cap ($100–$1M presets); channel work draws from org balance, not individual seats
4. Review and launch — test in a private channel with /invite @Claude then @Claude summarize this channel

Admins control: per-channel tool access, token spend limits (org + per-channel), full audit log of actions and requesters, RBAC on Enterprise (who can invoke Claude), and network allowlists for outbound traffic.

Availability and migration

Claude Tag vs Claude Code in Slack

Anthropic’s framing: Claude Code remains fastest for solo synchronous work; Claude Tag is Claude Code made multiplayer, async, and proactive across your whole team.

What’s next

Anthropic plans just-in-time credential grants for sensitive one-off actions and identity-aware overlays for complex clearance structures — adding user-level permission checks on top of channel-scoped agent access.

Summary

Headroom is an Apache 2.0 context-compression layer for AI agents that shrinks tool outputs, logs, RAG chunks, files, and conversation history before they reach the LLM — typically cutting input tokens by 60–95% while preserving answer quality, with originals retrievable on demand.

%%{init: {"theme": "base", "themeVariables": {"background": "transparent", "lineColor": "#000000"}}}%%
graph TD
    A[Agent / App] --> B[Headroom]
    B --> C[CacheAligner]
    C --> D[ContentRouter]
    D --> E[SmartCrusher JSON]
    D --> F[CodeCompressor AST]
    D --> G[Kompress-base text]
    E --> H[CCR local store]
    F --> H
    G --> H
    H --> I[Compressed prompt]
    I --> J[LLM provider]
    J --> K[Response unchanged]
    H --> L[headroom_retrieve on demand]

    classDef agent fill:#8B0000,color:#fff
    classDef hook fill:#189AB4,color:#fff
    classDef decision fill:#444,color:#fff

    class A agent
    class B hook
    class J agent
    class D decision
    class H hook

What Headroom solves

Agent workloads explode context fast: a single grep across a monorepo, an incident log dump, or a 100-result code search can consume tens of thousands of tokens before the model reasons at all. Headroom intercepts that payload locally, routes it to a content-specific compressor, and forwards a smaller prompt — while caching originals so nothing is permanently lost.

Headroom sits between your agent and the provider: bulky tool output goes in, a smaller prompt comes out, and the same factual answer is still reachable.

Compression pipeline

All four entry points share one lifecycle: Setup → Pre-Start → Input Received → Input Routed → Input Compressed → Input Remembered → Pre-Send → Response Received. Transforms are independent and fail open — if a stage cannot compress safely, the original content passes through unchanged.

Stage 1 — CacheAligner

Dynamic values (dates, UUIDs, session tokens) are stripped from the stable system-prompt prefix and appended to the tail. That keeps Anthropic cache_control, OpenAI prefix caching, and Google CachedContent hitting on repeated calls instead of invalidating daily.

Stage 2 — ContentRouter + compressors

SmartCrusher is where most savings land: it parses JSON tool output, runs field-level statistical analysis (variance, uniqueness, change points), samples representative rows with the Kneedle algorithm on bigram coverage, and always keeps errors, anomalies, and distribution boundaries. Retention split: 30% from array start (schema), 15% from end (recency), 55% by importance score.

Stage 3 — Context fitting

Rolling Window (default) drops oldest turns first while preserving the system prompt and recent messages; tool call/response pairs are removed atomically. IntelligentContext scores every message on six dimensions — recency, semantic similarity, TOIN importance, error indicators, forward references, token density — and evicts lowest-scored content first, with dropped text stored in CCR for retrieval.

CCR: reversible compression

Compress-Cache-Retrieve (CCR) is Headroom’s differentiator versus one-way CLI wrappers. When SmartCrusher shrinks 1,000 search hits to 15 representative rows, the full payload is hash-indexed in a local store (SQLite). If the model needs detail, it calls headroom_retrieve with the hash — or the proxy exposes an equivalent ccr_retrieve tool.

Compression is not deletion: originals live locally with a TTL so the agent can pull the full dataset back when the summary is not enough.

from google import genai
from headroom import compress

client = genai.Client()
messages = [{"role": "user", "content": huge_tool_output}]
compressed, meta = compress(messages, model="gemini-2.5-flash")
# meta includes CCR hash for later retrieval

Three ways to deploy

Whether you embed compression, run a local gateway, or expose MCP tools, the same pipeline runs underneath.

Proxy — zero code changes

# Terminal 1
headroom proxy --port 8787

# Terminal 2 — any OpenAI-compatible client
export ANTHROPIC_BASE_URL=http://127.0.0.1:8787
claude

The proxy is OpenAI and Anthropic-compatible. MCP tools are also auto-exposed at /mcp for remote agents (Docker, cloud) via Streamable HTTP.

MCP — on-demand compression

pip install "headroom-ai[mcp]"
headroom mcp install   # registers with Claude Code / Cursor
claude                 # gains headroom_compress, headroom_retrieve, headroom_stats

MCP and proxy complement each other: the proxy compresses all upstream traffic before the model sees it; MCP tools let the model compress specific blobs after receipt. They operate on different data paths and do not double-compress.

Framework integrations

Agent compatibility

Cross-agent memory and failure learning

SharedContext and cross-agent memory let Claude, Codex, and Gemini share a compressed store with agent provenance and auto-dedup — useful when you switch tools mid-task. headroom learn mines failed sessions offline and writes corrections into CLAUDE.md, AGENTS.md, or GEMINI.md. A separate headroom learn --verbosity mode infers how terse you prefer replies from interruption patterns in past sessions.

Output token reduction

Input compression is only half the bill — output tokens on frontier models can cost 5× input. With HEADROOM_OUTPUT_SHAPER=1, the proxy appends terse-steering notes to the system prompt tail (preserving prefix cache hits) and dials thinking effort down on routine post-tool turns while keeping full effort for new questions and errors.

Output savings are reported as honest estimates with confidence intervals; set HEADROOM_OUTPUT_HOLDOUT=0.1 for a measured control group.

export HEADROOM_OUTPUT_SHAPER=1
headroom proxy --port 8787
headroom output-savings   # e.g. Reduction: 31.7% (95% CI 27.7% … 35.7%) [estimated]

Benchmarks and proof points

Reproduce tier-1 evals locally: python -m headroom.evals suite --tier 1. The README demo shows a live run: 10,144 → 1,260 tokens with the same FATAL log line found.

What Headroom does not touch

• User messages — intent preserved exactly
• System prompts — content kept; only dynamic fragments relocated for caching
• Model responses — returned unchanged from the provider (unless output shaper enabled)
• Short tool output — under ~200 tokens passes through (overhead > savings)
• Code — unchanged unless AST compression is explicitly enabled

Compared to alternatives

Headroom bundles RTK for shell-output rewriting and can delegate CLI context to lean-ctx via HEADROOM_CONTEXT_TOOL=lean-ctx.

Install and operations

pip install "headroom-ai[all]"     # Python 3.10+
npm install headroom-ai            # TypeScript
docker pull ghcr.io/chopratejas/headroom:latest

headroom wrap claude               # fastest agent path
headroom perf                      # session savings dashboard
headroom update                    # in-place upgrade (pip/pipx/uv)

Granular extras: [proxy], [mcp], [ml], [code], [memory], [langchain], [agno], [evals]. Data stays on your machine when running locally; disable telemetry with HEADROOM_TELEMETRY=off. Corporate SSL-inspection environments may need Rust pre-installed and trusted CA bundles for ONNX Runtime and HuggingFace model downloads.

Summary

Google’s Gemini Interactions API reached general availability on 22 June 2026 and is now the primary interface for Gemini models and agents — replacing generateContent as the default in Google AI Studio, official docs, and new frontier agent features.

%%{init: {"theme": "base", "themeVariables": {"background": "transparent", "lineColor": "#000000"}}}%%
graph TD
    A[Developer] --> B[Interactions API]
    B --> C{model or agent?}
    C -->|model ID| D[Gemini inference]
    C -->|agent ID| E[Managed Agent sandbox]
    D --> F[Typed steps timeline]
    E --> F
    B --> G[background=true]
    G --> H[Async Deep Research / agents]
    F --> I[previous_interaction_id]
    I --> J[Server-side state 55-day retention]

    classDef agent fill:#8B0000,color:#fff
    classDef hook fill:#189AB4,color:#fff
    classDef decision fill:#444,color:#fff

    class B hook
    class E agent
    class D agent
    class H agent
    class C decision

What GA means for Gemini developers

The Interactions API launched in public beta in December 2025. GA brings a stable schema, Managed Agents with remote Linux sandboxes, background execution, typed execution steps, Flex/Priority service tiers, and documentation that defaults to Interactions everywhere. generateContent remains supported for mainline models, but long-running agent capabilities will increasingly ship exclusively on Interactions.

One endpoint: model inference or managed agent

The core design: pass a model ID for inference or an agent ID for autonomous multi-step work. Same SDK call shape, same endpoint (POST /v1beta/interactions).

from google import genai

client = genai.Client()

# Talk to a model
interaction = client.interactions.create(
    model="gemini-3.5-flash",
    input="Explain quantum entanglement simply.",
)

# Run a managed agent
interaction = client.interactions.create(
    agent="antigravity-preview-05-2026",
    input="Plot solar energy growth globally and make HTML slides.",
    environment="remote",
)

Key GA capabilities since December beta

Managed Agents and the Antigravity sandbox

antigravity-preview-05-2026 is the default managed agent. A single interactions.create() with environment="remote" provisions a sandbox where the agent reasons, runs code, browses the web, and manages files. You can also define custom agents with instructions, skills, and data sources. Other built-in agents include Deep Research variants (deep-research-preview-04-2026, deep-research-max-preview-04-2026) and Computer Use (gemini-2.5-computer-use-preview).

Background execution for long-running work

Set background=true on any interaction. The server processes asynchronously — ideal for Deep Research, Deep Think, and multi-step agent tasks. Poll or stream status; retrieve the completed interaction when done. Cancel in-flight background jobs with the cancel endpoint.

interaction = client.interactions.create(
    agent="deep-research-max-preview-04-2026",
    input="Research the state of solid-state batteries in 2026.",
    background=True,
)

# Poll until status is complete, then read interaction.steps

From roles to typed steps

The biggest schema change: instead of role: user / role: model message blobs, every action is a typed step — user_input, thought, function_call, model_output, and more. Streaming emits step.start, step.delta, step.stop events. This makes agent UIs, debugging, and intermediate rendering (search widgets, thoughts) straightforward. SDK convenience: interaction.output_text extracts final text; complex multimodal responses require iterating steps.

Server-side state and multi-turn chat

Interactions store server-side by default (store=true). Continue conversations with previous_interaction_id instead of resending full history. Opt into stateless mode with store=false when you manage history client-side. Paid tier retains interactions for 55 days.

# Continue a conversation
follow_up = client.interactions.create(
    model="gemini-3.5-flash",
    input="Now explain it for a 10-year-old.",
    previous_interaction_id=interaction.id,
)

Flex vs Priority service tiers

Per-interaction tier selection: Flex cuts cost by roughly 50% for batch and non-latency-sensitive workloads. Priority optimises for lower latency on interactive applications. Errors now pinpoint the exact invalid field in requests.

Migrating from generateContent

Google published a field-by-field migration guide. Docs include a toggle to switch code snippets back to legacy format. Automate migration with the gemini-interactions-api skill:

npx skills add google-gemini/gemini-skills --skill gemini-interactions-api

# Then in Gemini CLI or Jules:
# /gemini-interactions-api migrate my app to the interactions api

Ecosystem and getting started

Available via Python and JavaScript SDKs, REST, and partner integrations (LiteLLM, Eigent, Agno). Grab an API key from Google AI Studio. Full reference: Interactions API reference and quickstart.

Summary

AI loops replace the one-prompt-at-a-time habit with a goal the model keeps working toward — planning, executing, verifying against objective criteria, and iterating until done or a hard stop limit is hit. Anatoli Kopadze’s X Article breaks down how Claude Code /goal and /loop, ChatGPT self-check prompts, and Telegram Mira Skills each implement the same pattern at different complexity levels.

%%{init: {"theme": "base", "themeVariables": {"background": "transparent", "lineColor": "#000000"}}}%%
graph TD
    A[Set goal + verify gate] --> B[DISCOVER]
    B --> C[PLAN]
    C --> D[EXECUTE]
    D --> E{VERIFY}
    E -->|pass| F[DONE]
    E -->|fail| G[ITERATE with state]
    G --> B
    H[Stop condition] --> E
    I[State / memory] --> G

    classDef agent fill:#8B0000,color:#fff
    classDef hook fill:#189AB4,color:#fff
    classDef decision fill:#444,color:#fff

    class A agent
    class D agent
    class E decision
    class F agent
    class G hook
    class H decision

The slow way most people still use AI

The default workflow: type a request, wait, fix the output, ask again — every step routed through you. The AI never moves unless you push it. That works for one-off tasks but hits a ceiling fast: you are the engine, and the model is only the tool in your hand.

The alternative: give the goal once and let the system run the cycle itself — plan, execute, verify, fix weaknesses, repeat until the bar is met. Engineer Geoffrey Huntley frames it plainly: “You shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents.”

What a loop actually is

A prompt is a single instruction. A loop is a recursive goal the AI keeps working toward until completion. The canonical cycle from the article:

DISCOVER  →  work out what needs doing
PLAN      →  decide how to do it
EXECUTE   →  do the work
VERIFY    →  check it against the goal
ITERATE   →  not there yet? feed the result back in and repeat

Three parts people get wrong

The four-box test: do you even need a loop?

A loop is worth building only when all four conditions hold. Miss one and a single good prompt is cheaper:

• The task repeats at least weekly — setup cost must pay back
• Something can automatically reject bad output (tests, linter, type checker, hard rule)
• The agent can finish end-to-end without handing half back to you
• “Done” is objective — not a matter of taste where humans still win

The coding loop: five building blocks

Loops took off in software first because code is trivially verifiable — tests pass or fail. Claude Code and OpenAI Codex now ship primitives for all five blocks:

▸ LOOP SPEC
GOAL: every test in /tests/auth passes, lint is clean, no type errors.

EACH ITERATION:
  1. run the test suite and read every failure
  2. pick the single highest-impact failure
  3. write the smallest change that fixes it
  4. re-run tests, lint, and type checker

VERIFY: green tests + zero lint warnings + zero type errors
STOP WHEN: verify passes, OR 8 iterations reached
ON STOP: summarize what changed and what still fails

The cost nobody mentions

Loops bill in tokens, and cost compounds. Every iteration re-sends the full context — goal, code, last result, failures — and that pile grows each pass. Ten iterations is not ten equal prompts; each prompt gets bigger. Maker-and-checker doubles the bill because two models read the work.

Without a hard gate, loops fail quietly — the “Ralph Wiggum loop” where the agent declares victory early and keeps billing while producing nothing. Production teams add iteration caps, token budgets, cheap models on boring steps, and monitoring.

Build order that survives in production

1. Get ONE manual run reliable first.
2. Turn that into a skill (save the instructions).
3. Wrap the skill in a loop (add the gate + stop condition).
4. THEN put it on a schedule.

Scheduling something you have not proven by hand is how loops blow up while you sleep.

Build a basic loop in any LLM (no code)

Paste this into Claude or ChatGPT to feel the loop without tooling. It forces PLAN → DO → VERIFY → DECIDE until every criterion scores 8+:

▸ SELF-CHECKING LOOP  (paste into Claude or ChatGPT)
You will work in a loop until the task meets the bar.

TASK:
[describe exactly what you want produced]

SUCCESS CRITERIA (be strict, no soft passes):
- [criterion 1]
- [criterion 2]
- [criterion 3]

LOOP PROTOCOL, repeat every turn:
1. PLAN   - state the single next step.
2. DO     - produce or improve the work.
3. VERIFY - score the result 1-10 on each criterion.
            Be brutally honest. List exactly what is still weak.
4. DECIDE - if every criterion is 8+, print "FINAL" and stop.
            Otherwise print "ITERATING" and go again.

RULES:
- Never call it done until every criterion is 8 or higher.
- Each pass must fix the weakest score from the last VERIFY.
- Do not ask me questions. Make a sensible assumption and keep going.

Begin. Run the loop until FINAL.

What is still missing: you are the trigger. Close the tab and the loop vanishes. No schedule, no event trigger, no background execution.

Claude Code: /goal vs /loop vs /schedule

The expensive mistake: using /loop on work with a finish line (re-runs blindly after done) or /goal to poll something external (condition cannot become true no matter how hard Claude works). Official docs: /goal, /loop and scheduled tasks.

GPT and Codex loops

ChatGPT supports the same self-checking prompt pattern manually. OpenAI’s agent improvement flywheel (traces → human/model feedback → evals → harness changes via Codex) is the production version: run agent, score output, diagnose failures, persist lessons, repeat. Codex automations and scheduled exec runs mirror Claude’s /schedule for cloud-side recurring jobs. The underlying pattern is identical — only the verify gate and persistence layer differ.

Mira: life loops inside Telegram

The article’s Mira refers to @mira on Telegram — a consumer agent with ~1M monthly users, not a coding framework. The distinction from ChatGPT: ChatGPT answers; Mira acts. Skills are natural-language loops with triggers, multi-step actions across connected apps (500+ via Composio — Gmail, Calendar, Linear, GitHub, Notion), and persistent memory across sessions and group chats.

▸ SKILL
"Every weekday at 7am, check my Gmail and Google Calendar.
Send me a short brief: my 3 most important meetings, anything
urgent in the inbox, and one thing I said I'd follow up on but
haven't. Keep it under 120 words."

That is a real loop: time trigger + multi-app action + autonomous delivery. No code, hosting, or API keys — described in one message. Example Skills from the article span work (meeting prep, Linear tickets, weekly digests), creators (voice note → multi-platform posts, image/video generation), voice (transcription, TTS, group chat summaries), and life (habit streaks, journaling, flight price watches, news digests).

Quick start commands

@mira, plan my week
@mira, summarize this chat
@mira, remind me to review PRs every Monday at 9am
@mira, write a post about [topic] for X and Instagram

When loops are a trap

• One-off tasks where setup never pays back
• Subjective quality with no objective verify gate
• Agent cannot complete the work without constant human handoff
• No iteration cap — silent billing on half-finished jobs
• Scheduling before one reliable manual run exists

Summary

Agent-Native is Builder.io’s open-source framework for building apps where agents and UI are equal citizens — one defineAction() powers clicks, chat tools, HTTP, MCP, A2A, CLI, and scheduled jobs over shared SQL state, so agents act inside real products instead of beside them.

%%{init: {"theme": "base", "themeVariables": {"background": "transparent", "lineColor": "#000000"}}}%%
graph TD
    A[defineAction] --> B[React UI hooks]
    A --> C[In-app agent tools]
    A --> D[HTTP API]
    A --> E[MCP server]
    A --> F[A2A agents]
    A --> G[CLI]
    A --> H[Scheduled jobs]
    I[(SQL database)] --> B
    I --> C
    C --> J[Agent runtime]
    J --> K[Skills + memory]
    J --> L[Observability]

    classDef agent fill:#8B0000,color:#fff
    classDef hook fill:#189AB4,color:#fff
    classDef decision fill:#444,color:#fff

    class A agent
    class C agent
    class J agent
    class B hook
    class E hook
    class F hook
    class I agent

The problem: chat beside the app

Most “AI features” bolt a chat sidebar onto an existing SaaS shell. The agent cannot reliably mutate app state, share auth with the UI, or expose the same operations a button click would trigger. Raw coding agents (Claude Code, Codex) are powerful but do not ship multi-tenant dashboards, live sync, or product-grade persistence. Agent-Native targets rung 3 on the framework’s ladder: agent and application as partners over one database, one action layer, and one runtime.

One action, seven surfaces

The central primitive is defineAction() in @agent-native/core. You declare a Zod schema, a run() function, and optional metadata; the framework auto-discovers files under actions/ and exposes them everywhere the product needs them. The ActionRunContext.caller field tells your business logic whether the invocation came from the UI, agent tool loop, HTTP, MCP, A2A, or CLI.

import { defineAction } from "@agent-native/core";
import { z } from "zod";

export default defineAction({
  description: "Create a reply to an email",
  schema: z.object({
    emailId: z.string(),
    body: z.string(),
  }),
  http: { method: "POST" },
  publicAgent: { expose: true, readOnly: false },
  run: async ({ emailId, body }, ctx) => {
    await db.insert(replies).values({ emailId, body });
  },
});

What ships in the framework

Agents and UI, fully connected

Official docs describe six architecture rules: data lives in SQL; all AI routes through the agent; operations go through actions; UI and agent stay live-synced; the agent can modify app code over time; ephemeral UI state persists in SQL (application_state). Humans and agents co-edit documents via Yjs/TipTap collaboration. Select text and hit Cmd+I for context-aware commands. Tag another agent from any app and they coordinate over A2A on a shared workspace deploy.

Production templates (not scaffolds)

The monorepo ships 15+ cloneable open-source SaaS apps under templates/ — complete products you fork and customise, not empty starters. A workspace deploy mounts multiple apps under one origin with shared auth and zero-config cross-app A2A.

Skills without scaffolding a full app

The lowest-friction entry is installing app-backed skills into Claude Code, Codex, Cursor, Pi, or GitHub Copilot:

npx @agent-native/core@latest skills add visual-plan

/visual-plan opens a structured, reviewable plan with diagrams, wireframes, file-by-file implementation maps, and commentable annotations before code lands. /visual-recap turns a PR or git diff into a high-altitude visual recap with a shareable review link. Hosted Plan app: plan.agent-native.com; MCP endpoint at /_agent-native/mcp.

Protocols and interoperability

Tech stack

Quick start

# Interactive — pick full template, chat shell, or headless
npx @agent-native/core@latest create my-app

# Minimal chat UI
npx @agent-native/core@latest create my-app --template chat

# Action-first, no UI shell
npx @agent-native/core@latest create my-agent --headless

cd my-app
pnpm install
pnpm action hello --name World
pnpm agent "Call hello for World"
pnpm dev

Agent-Native vs alternatives

Summary

Movez’s self-improving loop pairs Kimi K2.6’s 300-agent swarm — up to 4,000 coordinated steps per run — with an Opus 4.8 verification gate, so each completed task leaves behind reusable skills and constraints instead of resetting to zero on the next prompt.

%%{init: {"theme": "base", "themeVariables": {"background": "transparent", "lineColor": "#000000"}}}%%
graph TD
    A[Write spec] --> B[Review decomposition plan]
    B --> C[Kimi K2.6 swarm]
    C --> D[Structured file outputs]
    D --> E{Opus 4.8 verify gate}
    E -->|pass| F[Save Skill]
    E -->|fail| G[Patch + CONSTRAINTS.md]
    G --> C
    F --> H[Replay on new inputs]
    H --> I[Background agent]

    classDef agent fill:#8B0000,color:#fff
    classDef hook fill:#189AB4,color:#fff
    classDef decision fill:#444,color:#fff

    class A agent
    class C agent
    class E decision
    class F hook
    class G hook
    class I agent

What the X article argues

Most Kimi users treat it as a chatbox: one question, one answer, close the tab. Movez’s playbook treats Kimi K2.6’s Agent Swarm as an execution engine that can run hundreds of parallel sub-agents, emit real deliverables (PDFs, spreadsheets, code, decks), and compound across runs by saving verified workflows as Skills. The twist is architectural: Kimi does volume; Claude Opus 4.8 sits at a single verify gate whose only job is to stop flawed output from being promoted into permanent skills.

Kimi K2.6 swarm specs (verified numbers)

The 4,000-step figure is a total coordinated budget across the swarm, not 4,000 steps per agent. At a 300-agent ceiling that implies roughly a dozen tool steps each — specialised subtasks with bounded context windows, with only structured outputs flowing back to the coordinator. That is the structural reason long-horizon research does not collapse into lossy summarisation the way a single-thread agent does.

The compounding loop in one diagram

Why two models instead of one

Movez’s pattern is not “pick the benchmark winner.” Kimi K2.6 is optimised for cheap parallel execution at open-weight pricing; Opus 4.8 is positioned for judgment — planning nuance, catching its own mistakes, and refusing to rubber-stamp flawed results. The swarm’s known failure mode without verification is confident, under-cited claims and contradictory sub-agent outputs. Premium tokens at the verify gate are cheaper than permanently saving garbage into a Skill library.

The 10-step playbook (condensed)

Spec template (step 01)

# PROJECT: [name]
GOAL: [one sentence — the deliverable, not the topic]
SCOPE: [what's in, what's explicitly out]
RULES: [validation — what counts as a verified row/finding]
SOURCES: [official posts, papers, primary only — no aggregators]
OUTPUT: [file type / count / naming / format details]
ON CONFLICT: flag the row, never resolve silently
STOP CONDITION: [when to halt and report instead of guessing]

Enable swarm via API

from openai import OpenAI

client = OpenAI(
    api_key="MOONSHOT_API_KEY",
    base_url="https://api.moonshot.ai/v1",
)

response = client.chat.completions.create(
    model="kimi-k2.6",
    messages=[{"role": "user", "content": "YOUR_SPEC_HERE"}],
    extra_body={
        "agent": {
            "type": "swarm",
            "max_agents": 300,
            "max_steps": 4000,
        }
    },
)

Moonshot’s API is OpenAI-compatible. Production guidance from third-party write-ups: cap max_agents to 10–30 for predictable tasks even though the ceiling is 300; stream responses to kill bad runs early; log token usage on every response.

What “self-improving” actually means

The model is not retraining weights between your runs. The system around it compounds: Skills capture proven workflows, document-to-skill captures domain voice, and CONSTRAINTS.md turns verify failures into hard rules. A competitor cannot copy that library in a week — it is built from months of verified runs on your data. That is the honest version of self-learning Movez describes, distinct from static LangGraph DAGs that behave identically on run #1 and run #50.

Summary

Open Knowledge Format (OKF) v0.1 is Google’s vendor-neutral open standard that turns the LLM-wiki pattern into portable markdown bundles — one concept per file, YAML frontmatter for queryable fields, and cross-links that form a knowledge graph agents can traverse without an SDK or proprietary catalog.

%%{init: {"theme": "base", "themeVariables": {"background": "transparent", "lineColor": "#000000"}}}%%
graph TD
    A[Source systems] --> B[Producer]
    B --> C[OKF bundle]
    C --> D{Consumers}
    D --> E[AI agent]
    D --> F[HTML visualizer]
    D --> G[Knowledge Catalog]
    C --> H[index.md]
    C --> I[concept .md files]
    I --> J[YAML frontmatter]
    I --> K[Markdown body]
    I --> L[Cross-links graph]

    classDef agent fill:#8B0000,color:#fff
    classDef hook fill:#189AB4,color:#fff
    classDef decision fill:#444,color:#fff

    class A agent
    class B hook
    class C agent
    class E agent
    class F hook
    class G hook
    class D decision

Why context fragmentation blocks agents

Foundation models improve every quarter, but agent accuracy still hinges on internal context: table schemas, metric definitions, join paths, runbooks, deprecation notices, and tribal knowledge locked in senior engineers’ heads. Today that knowledge is scattered across metadata catalogs, wikis, shared drives, code comments, and notebook cells — each with its own API, schema, and export format.

Knowledge as a living wiki

Andrej Karpathy’s LLM Wiki pattern argues that agents do not get bored updating cross-references and can touch many files in one pass — the bookkeeping humans abandon in personal wikis. Similar patterns appear as Obsidian vaults wired to coding agents, metadata-as-code repos inside data teams, and repos full of index.md / log.md artefacts. OKF formalises the interoperability surface so Karpathy-style wikis, team wikis, and catalog exports can cooperate without translation.

Bundle anatomy: one concept, one file

An OKF knowledge bundle is a directory tree of UTF-8 markdown files. Each concept — a table, metric, API, playbook, or abstract idea — maps to exactly one .md file. The file path is the concept ID (path without .md). No runtime, database, or account is required: ship as a git repo, tarball, or mounted subdirectory.

sales/
├── index.md
├── datasets/
│   ├── index.md
│   └── orders_db.md
├── tables/
│   ├── index.md
│   ├── orders.md
│   └── customers.md
└── metrics/
    ├── index.md
    └── weekly_active_users.md

Concept document shape

---
type: BigQuery Table
title: Orders
description: One row per completed customer order.
resource: https://console.cloud.google.com/bigquery?p=acme&d=sales&t=orders
tags: [sales, revenue]
timestamp: 2026-05-28T14:30:00Z
---

# Schema

| Column        | Type      | Description                              |
|---------------|-----------|------------------------------------------|
| `order_id`    | STRING    | Globally unique order identifier.        |
| `customer_id` | STRING    | FK to [customers](/tables/customers.md). |

# Joins

Joined with [customers](/tables/customers.md) on `customer_id`.

Frontmatter specification (v0.1)

Reserved files and progressive disclosure

All other .md files are concept documents. Bundles may declare okf_version: "0.1" in root index.md frontmatter — the only place frontmatter is permitted on an index file.

Cross-links build a richer graph than folders

Concepts link with standard markdown. Bundle-relative paths starting with / (e.g. /tables/customers.md) are preferred because they stay stable when files move within subdirectories. Link semantics are conveyed by surrounding prose — joins-with, depends-on, references — not by link type. Consumers must tolerate broken links (targets may be not-yet-written knowledge).

Three design principles

• Minimally opinionated — only type is required; taxonomy, body sections, and tooling are producer choices.
• Producer/consumer independence — human-authored bundles, LLM-generated exports, and catalog pipelines all speak the same contract.
• Format, not platform — no proprietary SDK, cloud lock-in, or account needed to read or write OKF.

Conformance and permissive consumption

A bundle is conformant when every non-reserved .md file has parseable YAML frontmatter with a non-empty type, and reserved files follow index/log structure when present. Consumers must not reject bundles for missing optional fields, unknown types, extra frontmatter keys, broken links, or absent index.md files — the spec is deliberately permissive so partially generated agent output remains useful.

Reference implementations Google ships

Repository: GoogleCloudPlatform/knowledge-catalog/okf. Full spec: okf/SPEC.md. Community guide with validator and templates: openknowledgeformat.com.

How OKF compares to adjacent patterns

Getting started: minimal conformant concept

# Create bundle root
mkdir -p okf/tables && cd okf

# Root index for progressive disclosure
cat > index.md <<'EOF'
# Sales knowledge

* [Orders table](/tables/orders.md) - One row per completed customer order.
EOF

# Concept file — only `type` is strictly required
cat > tables/orders.md <<'EOF'
---
type: BigQuery Table
title: Orders
description: One row per completed customer order.
tags: [sales]
---

# Schema

| Column | Type | Description |
|--------|------|-------------|
| order_id | STRING | Unique order identifier. |
EOF

# Ship as git repo or tarball — any agent can cat the files

Summary

DeepEval is an Apache-2.0 Python framework that brings pytest-style unit tests to LLM apps—scoring agents, RAG pipelines, and chatbots with 50+ research-backed metrics, optional trace-level evals, and a v4 “vibe coding” loop where your IDE agent runs deepeval test run and patches failures.

%%{init: {"theme": "base", "themeVariables": {"background": "transparent", "lineColor": "#000000"}}}%%
graph TD
  A[Dataset / goldens] --> B[Your LLM app]
  B --> C[LLMTestCase + traces]
  C --> D[Metrics layer]
  D --> E{Score vs threshold}
  E -->|Pass| F[CI green]
  E -->|Fail| G[Metric reason + span]
  G --> H[Coding agent patch]
  H --> B
  C --> I[Confident AI optional]
  I --> J[Reports + production monitor]

  classDef agent fill:#8B0000,color:#fff
  classDef hook fill:#189AB4,color:#fff
  classDef decision fill:#444,color:#fff

  class B,F agent
  class D,I,H hook
  class E decision

What DeepEval is

Each test is an LLMTestCase (single-turn) or ConversationalTestCase (multi-turn) with input, actual_output, optional expected_output, and retrieval_context. Metrics return a 0–1 score, pass/fail against a threshold, and a natural-language reason—the signal coding agents use in the v4 iteration loop.

Metric families

Two evaluation shapes

Framework integrations (preferred over hand-rolled @observe) cover OpenAI Agents, LangChain/LangGraph, Anthropic, CrewAI, Pydantic AI, LlamaIndex, Google ADK, AWS AgentCore, and more—auto-instrumenting LLM and tool spans for scored traces.

CI/CD and local runs

pip install -U deepeval

# test_chatbot.py — use assert_test, not evaluate(), inside pytest files
deepeval test run test_chatbot.py -n 4   # parallel workers

deepeval login    # optional: push reports to Confident AI
deepeval view     # open latest test run in browser

Test files must be named test_*.py. In CI, always use assert_test() inside test functions—evaluate() is for notebooks. Flags like --identifier, --num-processes, and --ignore-errors support repeatable agent-driven iteration rounds.

Vibe-coding loop (v4)

DeepEval v4 targets IDE agents (Cursor, Claude Code, Codex, Windsurf). Install the agent skill with npx skills add confident-ai/deepeval --skill deepeval, commit suites under tests/evals/, then let the agent:

• Generate goldens with deepeval generate if no dataset exists
• Run deepeval test run and read failing metric reason strings
• Patch the smallest app change (prompt, retriever, tool schema)—not thresholds
• Re-run until scores improve without regressions

Docs ship llms.txt and per-page .md URLs so agents can ingest the metrics catalog without scraping HTML.

Confident AI (optional platform)

DeepEval is local-first. Confident AI (same team) adds shared datasets, testing reports, production trace monitoring, and an MCP server so agents can pull datasets and inspect traces from the IDE. It is optional—offline evals work without an account.

Summary

Context engineering is how you stop AI agents from going sloppy around step 15—by curating what the model sees (system prompt, tools, history, RAG, memory) so the finite context window stays high-signal instead of filling with stale tool dumps.

%%{init: {"theme": "base", "themeVariables": {"background": "transparent", "lineColor": "#000000"}}}%%
graph TD
  A[Agent turn starts] --> B[Collect sources]
  B --> C[Select for this step]
  C --> D[Compress to budget]
  D --> E[Arrange stable prefix first]
  E --> F[LLM call]
  F --> G{Step quality OK?}
  G -->|Yes| H[Next step]
  G -->|No| I[Diagnose failure mode]
  I --> J[Write / Isolate / prune]
  J --> B
  H --> B

  classDef agent fill:#8B0000,color:#fff
  classDef hook fill:#189AB4,color:#fff
  classDef decision fill:#444,color:#fff

  class A,F,H agent
  class B,C,D,E,J hook
  class G decision

Why agents fail after ~15 steps

Rahul’s playbook opens with a pattern most builders recognise: the first ten agent steps look sharp, then wrong tool calls, forgotten instructions, and shallow outputs appear—not because the model changed, but because context rot set in. Anthropic frames context engineering as optimising token utility across multi-turn loops; LangChain’s OS analogy treats the context window as RAM that degrades when crowded, often well before the hard limit (Chroma’s study showed decline across 18 frontier models as length grew).

Seven things fighting for the same window

The four strategies: Write, Select, Compress, Isolate

Four failure modes (and fixes)

Production workflow: phased compaction

Dex Horthy’s frequent intentional compaction pattern (cited in the playbook) structures long coding runs into phases, each ending in a compact artifact and a fresh context:

• Research — sub-agents explore; parent gets research.md (isolate + write + compress)
• Plan — new window with research + problem only; human review gate
• Implement — new window with plan + progress.md tracker

Staying under 40–60% of context capacity per phase avoids the “sloppy step 20” cliff. Claude Code’s auto-compaction at ~95% and Manus’s KV-cache-aware prefix ordering follow the same principle: stable instructions and tool defs at the top (cacheable), dynamic tail at the bottom.

The universal turn pipeline

Summary

Vercel eve is an open-source, filesystem-first TypeScript framework that treats an AI agent as a folder of files—instructions, tools, skills, channels—and compiles it into a production agent with durable sessions, sandboxes, approvals, and evals already wired in.

%%{init: {"theme": "base", "themeVariables": {"background": "transparent", "lineColor": "#000000"}}}%%
graph TD
  A[agent/ directory] --> B[eve compiler]
  B --> C[Durable session]
  B --> D[Sandbox]
  B --> E[Tools + skills]
  B --> F[Channels]
  C --> G[AI Gateway model calls]
  D --> H[bash / code / files]
  E --> I[MCP + APIs via Connect]
  F --> J[Slack / Discord / HTTP / cron]
  B --> K[OpenTelemetry traces + evals]
  B --> L[vercel deploy]

  classDef agent fill:#8B0000,color:#fff
  classDef hook fill:#189AB4,color:#fff
  classDef decision fill:#444,color:#fff

  class A,G agent
  class B,D,E,I,K hook
  class C decision

An agent is a directory

The pitch mirrors early Next.js: stop hand-rolling the same agent plumbing on every project. Vercel says hundreds of internal agents exposed the same shape—model loop, state, sandbox, credentials, channels—so eve codifies that shape and discovers files at build time, similar to how Next turns folders into routes.

Production primitives included

Minimal setup

npx eve@latest init my-agent
# installs deps, inits git, starts dev TUI

# agent/agent.ts
import { defineAgent } from "eve";
export default defineAgent({ model: "anthropic/claude-opus-4.8" });

# agent/tools/run_sql.ts — filename = tool name, Zod schema + execute
# eve dev — terminal UI + HTTP API on same structured events

HTTP clients create a session with POST /eve/v1/session, stream NDJSON from GET /eve/v1/session/:id/stream, and continue with the returned continuationToken. Models route through AI Gateway with provider fallbacks; on Vercel you authenticate with OIDC instead of copying API keys.

Ship and operate like normal software

An eve project is a standard Vercel app: vercel deploy ships the same directory that ran locally. Preview deployments carry channels too—your team can test the next Slack bot before it replaces production. Sessions started before a deploy finish on the version they began on.

Channels are one CLI command each (eve channels add slack writes channels/slack.ts). Launch integrations include Slack, Discord, Teams, Telegram, Twilio, GitHub, and Linear, plus custom defineChannel adapters. Schedules deploy as Vercel Cron Jobs.

How Vercel uses eve internally

Vercel reports agent-triggered deployments rose from under 3% a year ago to about 29% today, with half of deployments expected to come from agents soon. Those agents now live in one monorepo with shared conventions instead of separate stacks per team.

Summary