✨Article Summary (AI Generated)

This article uses a 15,400-token login bug fix scenario to dissect the context compaction strategies of three mainstream CLI agents: Codex CLI, Claude Code, and OpenCode. Codex CLI takes a single-layer "handoff summary" approach; Claude Code employs a three-tier progressive mechanism — tool result trimming, Prompt Cache-friendly strategies, and a 9-section structured LLM summary; OpenCode implements "stepped governance" through non-destructive timestamp-based message hiding paired with a 5-heading LLM summary. The article reveals a core insight: the best context management isn't about endlessly expanding memory capacity, but learning to forget with precision.

When using AI agents for deep programming tasks, you've surely encountered this predicament: at first, the AI is sharp and responsive, hitting every mark; but as conversation turns accumulate, it seems to get progressively dumber.

When context is nearly exhausted, the AI rushes to finish, leading to poor results — the community calls this Context Anxiety, and just like us humans, haste makes waste. To keep the conversation going, the agent must shed some memories (compress — compact). But how to shed, what to shed, and how to recover afterward have become key markers of whether an agent runtime is truly mature.

Today, let's tear apart three mainstream CLI agents — Codex CLI, Claude Code, and OpenCode — and see how each performs their "compression magic" when facing the same login bug.

Note: This analysis is based on the open-source repository logic of Codex CLI and OpenCode, along with community reverse engineering and leaked source code verification of the Claude Code runtime.

Scenario Replay: A 15,400-Token Login Bug Fix ​

Imagine you're fixing a login endpoint returning 401 Unauthorized. You summon your AI agent and embark on an intense debugging session.

Here's the complete conversation log:

Just 26 messages, yet they've consumed roughly 15,400 tokens. The five bolded tool results (#5, #8, #13, #21, #26) alone total about 12,500 tokens — 81% of the total. This data was critical during debugging, but once the bug is fixed, it becomes dead weight in the context. If left uncleaned, the next conversation turn might overflow the window and lose the system prompt or the user's core requirements.

Codex CLI: Writing a Crisp "Handoff Memo" ​

OpenAI's Codex CLI (source, Rust implementation) takes an approach that feels very intuitive to humans: summarize and replace.

Its core idea can be captured in one sentence: hand the entire conversation to an LLM to write a "handoff summary," then replace the original history with that summary.

Dual-Path Design ​

Codex offers two compression paths:

1. Local path (compact.rs): The client calls an LLM to generate the summary, compatible with any model provider.
2. Remote path (compact_remote.rs): Directly calls OpenAI's internal API endpoint responses/compact, letting the server handle compression. OpenAI models only.

Note that "local" and "remote" here don't refer to whether an LLM call is needed — both paths require LLM involvement. The difference is where the core "generate summary" step runs. In the local path, the client constructs the summarization prompt (loaded from the built-in template templates/compact/prompt.md), streams the LLM API call via ModelClientSession, and processes the returned result — the entire orchestration happens on your machine, so it works with any model provider. In the remote path, the client sends the prepared conversation history and tool definitions to OpenAI's compact_conversation_history endpoint for server-side summary generation — but the client is far from hands-off. Before the call, it trims overly long function call histories and builds the complete prompt object including tool specifications and system instructions; after the call, it filters the results (e.g., discarding stale developer role messages, keeping only genuine user and assistant content), restores ghost snapshots for /undo functionality, and recalculates token usage.

In short, the remote path only outsources the "compression" step to OpenAI's server — pre-processing and post-processing remain client-side. The advantage is that OpenAI's server likely has dedicated optimizations for this endpoint (such as more economical models or internal caching) that aren't available through the generic API. This reflects OpenAI's vertical integration of their own infrastructure.

The Compression Flow in Detail ​

When taking the local path, Codex first extracts recent user messages (hard-capped at ~20,000 tokens), then sends a brief summarization prompt to the LLM. This prompt has just 4 core points:

You are performing a "context checkpoint compression." Generate a handoff summary for another LLM that will continue the task, including: current progress and key decisions, important constraints and user preferences, remaining TODOs, and critical data needed to continue work.

The keyword is "handoff" — it's not writing meeting minutes, but a briefing that lets the next person (model) hit the ground running.

Applied to our login bug scenario:

Breaking it down:

Notice the before-and-after — all messages collapse to just 4. Codex deeply respects "user intent": it physically deletes all assistant replies and tool-related messages, but preserves all user messages verbatim (#2 and #10).

It then inserts a fabricated assistant message containing a structured handoff summary. This summary includes the task objective, completed items, key architectural decisions, and remaining TODOs. For the new model, it doesn't need to see those massive file dumps and test stack traces — it just needs to know "the tests are fixed" and that's enough.

Auto-Trigger and Fallback ​

When token usage approaches the model's context window limit, Codex automatically triggers compression (no need for manual /compact). If space is still insufficient after compression, it falls back to more aggressive "head trimming" — chopping from the earliest messages to ensure the conversation can continue.

The biggest advantage of Codex's approach is its intuitiveness: the handoff summary concept is something every working professional understands. The downside is it's rather "all-or-nothing" — all AI replies and tool results get replaced by a summary, and if that summary misses a critical detail, it's truly gone forever.

Claude Code: Three-Tier "Precision Forgetting" ​

Anthropic's Claude Code takes a more nuanced approach. Rather than pursuing one-shot physical deletion, it designs three progressively stronger cleanup mechanisms — from light to heavy, avoiding LLM calls whenever possible.

Note: Claude Code is not open source. The following analysis is based on community reverse engineering and public materials; actual implementation may vary across versions.

Layer 1: Tool Result Trimming (Zero LLM Cost) ​

This is the most frequent and lightweight layer. No LLM call needed — it's purely a local rules engine that runs automatically before every request.

The logic is simple:

• Always protect the results of the most recent tool calls (active data can't be deleted)
• Older tool results beyond the protection window → replaced with [Old tool result content cleared] placeholder

Applied to our scenario:

This approach is remarkably clever: it maintains the AI's "flow state." The AI remembers it searched the code (#4's tool_call is still there), and remembers it read files (#7's tool_call is still there) — it just doesn't remember what the search returned or what the file contained. If it truly needs to look again, it will simply re-issue a read_file.

I find this layer's design exquisitely elegant — it achieves "selective amnesia" rather than "total forgetting." Like remembering you read a great book last year but forgetting the specifics — you can always flip through it again when needed.

Layer 2: Cache-Friendly Strategy (Prompt Cache) ​

This is Claude Code's signature move, and the unique differentiating advantage among the three.

Anthropic's API supports Prompt Cache — if the prefix of your message to the API matches the previous request, the server can reuse prior computation results, dramatically reducing cost and latency.

What does this mean? When cleaning messages, Claude Code strives to avoid modifying the first half of the message sequence. It takes a "surgical" approach: trimming only at the tail, ensuring the beginning of the message sequence remains absolutely consistent. The trade-off is slightly lower cleanup efficiency, but the payoff is maximized cache hit rate.

Applied to our scenario. Suppose after Layer 1 cleanup, the message sequence is #1-#26 (tool results already replaced with placeholders). Context still exceeds the limit and needs further trimming. A "naive" approach would delete from the earliest messages — but Claude Code doesn't do that:

The naive strategy on the left deletes the oldest messages, which seems reasonable, but the cost is that the entire prefix changes — the API cache completely invalidates, and the next request must compute from scratch. Claude Code's strategy on the right is the opposite: it would rather delete less, as long as the prefix portion of the message sequence remains identical to the previous request, allowing Anthropic's Prompt Cache to hit.

For long-running tasks (like having the AI help you refactor an entire module), this strategy yields significant cost savings — because most of each API request's content can hit cache, and you only pay for the newly added tail content.

Layer 3: 9-Section Structured LLM Summary (Last Resort) ​

When the first two layers can't prevent context from continuing to grow, the system triggers a final full summary. According to the source code, the auto-compaction threshold is effective context window - 13,000 tokens (where effective window = model context window - min(max output tokens, 20,000)).

However, even when the threshold is reached, the system doesn't jump straight to an LLM summary. When auto-compaction triggers, the system first tries Session Memory Compact — leveraging structured information already in session memory to substitute for a full LLM call. This means most auto-compactions don't even need an LLM call. Only when the session memory path is unavailable or insufficient does the system fall back to the traditional LLM summary flow, generating a structured summary with 9 fixed sections:

1. User's original intent
2. Core technical concepts
3. Files and code of interest
4. Errors encountered and how they were fixed
5. Problem-solving logic chain
6. Summary of all user messages
7. TODO items
8. What's currently being worked on
9. Suggested next steps

This summary has extremely strict requirements — the prompt demands the model directly quote key phrases from the original text rather than paraphrasing everything. This prevents "context drift" (the model subtly diverging from the original meaning during retelling).

Applied to our scenario:

After compression, Claude Code performs a series of post-processing steps — what I call "state reconstruction":

• Injects a lead-in at the beginning of the new conversation ("This session continues from a previous conversation...")
• Automatically re-reads recently edited files (up to 5 files, total budget 50,000 tokens, 5,000 tokens per file), ensuring the AI has the latest code
• Re-declares tool and skill definitions
• Project specifications in CLAUDE.md, as part of the system prompt, remain permanently resident and are unaffected by compression

Users can also attach custom instructions during manual compaction, such as /compact Focus on API changes, to steer the compression toward a specific focus.

Additionally, there's a passive fallback path: when the API returns a prompt_too_long error, the system automatically initiates a reactive compression and retries the request, ensuring users don't encounter an abrupt error from context overflow. To prevent infinite loops from repeated compression failures, automatic compaction pauses after 3 consecutive failures.

Claude Code's approach is the most complex of the three, but also the most "cost-effective" — most of the time it only needs to execute the Layer 1 rules engine cleanup, or complete compaction via the Session Memory path, requiring no extra LLM calls at all.

OpenCode: Prune First, Summarize Later — "Stepped Governance" ​

The open-source newcomer OpenCode (source, TypeScript + Effect-TS implementation) offers a more balanced strategy. In session/compaction.ts, it implements a stepped governance flow: use low-cost measures to free up space first, and only call on the LLM when truly necessary.

Step 1: Prune (Mark as Hidden, Not Physical Deletion) ​

OpenCode's first move isn't deletion — it's "marking." The rules are crystal clear:

• Only execute when pruning can free more than 20,000 tokens (minor cleanups aren't worth the hassle)
• Always preserve the most recent 40,000 tokens as a "safety cushion" (active work can't be touched)
• skill type tool outputs are never pruned (they contain operational instructions)
• Protect the full content of the last 2 user turns

Key design: Unlike Claude Code's placeholder replacement, OpenCode's pruning is not physical deletion. Instead, it stamps old messages with a compacted = Date.now() timestamp, making them "invisible" in subsequent requests. The data is still in the database — just hidden.

Key point: The data isn't truly lost. This leaves room for future history traversal features — if developers need auditing, or if the agent triggers some rollback logic, this data can be pulled back into context. This is a very forward-thinking design.

Step 2: LLM 5-Heading Summary ​

If things are still too bloated after pruning, OpenCode uses a hidden, dedicated agent (without disturbing the user's current interaction) to call an LLM and generate a summary. This summary follows a fixed 5-heading structure:

OpenCode has a wonderfully thoughtful design after summarization: it automatically replays the last user message. This ensures the agent's most recent memory point stays on the user's latest instruction, rather than on some cold summary text. The user is completely unaware that compression happened — your last message gets resent, the AI continues responding, as if nothing happened.

Another highlight: OpenCode follows the user's language. If you've been communicating in Chinese, its summary will also be in Chinese. For non-native English-speaking developers, this is a very friendly design.

I think OpenCode's approach is the most "developer-friendly" of the three — fully open-source code (TypeScript), modern architecture (Effect-TS), and the non-physical deletion design leaves ample room for extension. If you want to deeply customize compression behavior, OpenCode is the easiest to get started with.

The Three Musketeers Face Off ​

Let's put all three approaches side by side:

Input: 26 messages, ~15,400 tokens (same "fix login bug" scenario)

Differences Worth Expanding On ​

On whether to preserve user messages verbatim: Codex chooses to keep user messages intact, compressing only model responses. The advantage is that the AI can always look back at what you said, but the cost is reduced compression efficiency when user messages themselves are lengthy. Claude Code and OpenCode choose to compress everything into summaries — more aggressive but more space-efficient.

On caching: This is Claude Code's most unique advantage. The other two see significant changes in API request content after compression, essentially invalidating previous caches. Claude Code deliberately maintains prefix stability, allowing post-compression requests to still reuse prior caches. For long-running tasks, this translates to meaningful cost savings.

On non-physical deletion: OpenCode's timestamp marking approach is a forward-thinking design. While the current version doesn't implement history traversal, the data isn't truly lost, leaving the door open for future possibilities. Both Codex and Claude Code's compressions are irreversible.

Final Thoughts ​

If I were to describe these three with an analogy:

• Codex CLI is like a senior employee writing a handoff memo. They tear up the previous drafts and hand you a clear status report — blunt but effective.
• Claude Code is like a scholar with the ability to forget with precision. They first erase minor annotations in their books, and only when the bookshelf truly can't hold any more do they condense entire books into one-page outlines. They care deeply about the efficiency of flipping through books (caching).
• OpenCode is like a pragmatic stepped governance administrator. They first box up old files and label them (hide), and only summarize when absolutely necessary. Their most thoughtful touch? After summarizing, they remind you: "The last thing you said was about this, right?"

Ultimately, in 2026, the best context management isn't about endlessly expanding an LLM's memory capacity, but learning how to forget with precision. After all, an agent that remembers everything is often the one most easily distracted by noise.

References:

• Codex CLI: openai/codex (see codex-rs/core/src/compact.rs)
• Claude Code community resources:
  • Claude Code System Prompts
  • Sam Saffron's Gist
  • Claude Code's Compaction Engine
  • Leaked source repository (unofficial leak, used for verification)
• OpenCode: anomalyco/opencode (see packages/opencode/src/session/compaction.ts)

✨Article Summary (AI Generated)

The author shares his experience of distilling Harness Engineering knowledge into a reusable Agent Skill. After systematically studying sources from Anthropic, OpenAI, Martin Fowler, LangChain, and others, he identified seven core layers of harness design: project setup, context engineering, constraints & guardrails, multi-agent architecture, evaluation & feedback, long-running tasks, and diagnostics. The resulting harness-engineering skill covers three scenarios — new project scaffolding, diagnosing poor agent behavior, and continuous improvement — using a progressive-disclosure architecture. Quantitative evaluation showed 100% assertion pass rate with the skill vs. 83% without. The key insight: 80% of agent quality issues stem from harness gaps, not model limitations.

Why I Wrote This ​

Over the past two years, while using various AI coding assistants (Claude Code, Cursor, Copilot, etc.), I kept running into the same problem: Agent performance was inconsistent. While things have generally improved as models get better, the journey has been full of ups and downs.

Sometimes the code it writes perfectly matches the project style. Other times it acts like an intern on their first day — unaware of the project structure, ignoring conventions, and forgetting decisions we'd already agreed on.

I started applying Prompt Engineering techniques like structured prompts, few-shot examples, and demonstrations to stabilize AI output. Then I moved on to Context Engineering to enrich the agent's context and further stabilize its performance.

In recent weeks, a more systematic term has emerged: Harness Engineering.

When an agent performs poorly, 80% of the time the issue isn't the model — it's the Harness. — Anthropic

What is a Harness? Simply put:

• Model = CPU (the compute itself)
• Context Window = RAM (working memory)
• Harness = Operating System (scheduling, constraints, feedback, file system — all the infrastructure that makes the CPU work effectively)

You wouldn't expect a CPU to run efficiently on bare metal without an operating system. Similarly, you shouldn't expect a model to produce consistent output in a project without a Harness.

What I Learned ​

I systematically read articles from the following sources:

• Anthropic — Building effective agents, multi-agent research systems, harness design for long-running agents
• OpenAI — AGENTS.md design patterns, Context Engineering best practices
• Martin Fowler — The engineering philosophy of Harness Engineering ("Relocating Rigor")
• LangChain — Taxonomy of agent frameworks vs. runtimes vs. harnesses
• philschmid — The importance of Agent Harness in 2026
• Independent developers — Hermes Agent's self-evolution, Vue Lynx's design-notes-driven development
• Academic papers — Formalization of natural language agent harnesses

After reading everything, I found that while these articles approached the topic from different angles, their core ideas converged into seven layers:

So I Built a Skill ​

After reading all these articles, I realized these patterns are entirely reusable. Whether your project is a React frontend, Python backend, or Rust CLI tool — the design principles of a Harness are universal.

So I distilled this knowledge into an Agent Skill called harness-engineering.

What It Does ​

This skill has three core use cases:

Scenario 1: New Project Setup

When you start a new project and tell the agent "help me set up Harness engineering," it will:

1. Assess your project type, tech stack, and team size
2. Create an AGENTS.md (a table-of-contents-style agent navigation file)
3. Set up a docs/ directory (architecture, conventions, data models, etc.)
4. Configure the constraints layer (lint rules, type checking, pre-commit hooks)
5. Set up evaluation and feedback mechanisms

Scenario 2: Diagnosing Poor Agent Performance

This is the most interesting scenario. When you start complaining —

• "Why does it keep making the same mistake?"
• "It completely ignores our conventions!"
• "The code quality is terrible"

This skill gets triggered and guides the agent to diagnose gaps in the Harness layer, rather than blaming the model:

Scenario 3: Continuous Improvement

Every time a new reusable Harness pattern is discovered, update it in the skill so other projects can benefit too.

How It's Organized ​

The skill uses a progressive disclosure architecture:

harness-engineering/
├── SKILL.md              # Entry file (<60 lines), routes to specific references
└── references/
    ├── 01-project-setup.md       # Project setup
    ├── 02-context-engineering.md  # Context engineering
    ├── 03-constraints.md          # Constraints & guardrails
    ├── 04-multi-agent.md          # Multi-agent architecture
    ├── 05-eval-feedback.md        # Evaluation & feedback
    ├── 06-long-running.md         # Long-running tasks
    └── 07-diagnosis.md            # Diagnostics

SKILL.md itself is very concise — it acts like a router, directing the agent to read the relevant reference document based on the current scenario. This follows a core principle of Harness Engineering itself: progressive disclosure, load on demand.

Patterns That Impressed Me ​

A few patterns particularly resonated with me. Let me discuss them individually.

"Give a Map, Not a Manual" ​

I saw this concept in a tweet. The traditional approach is to write detailed step-by-step instructions (a manual) for the agent, but this makes the agent fragile — any deviation leaves it lost.

A better approach is to give the agent a map:

# Bad approach (manual)
Step 1: Open src/auth/login.ts
Step 2: Find the handleLogin function
Step 3: Add ... at line 42

# Good approach (map)
Auth system is in src/auth/. Login flow: login.ts → validate.ts → session.ts.
Rate limiting middleware is in src/middleware/rateLimit.ts — follow its pattern.
Every auth change needs a test in src/auth/__tests__/.

A map lets the agent navigate autonomously; a manual turns it into a fragile execution machine.

"Every Mistake → Add a Rule" ​

This pattern comes from cross-referencing multiple articles. The core idea:

1. The agent makes a mistake
2. You fix the mistake
3. Then you add a rule to permanently prevent that type of mistake from happening again

This rule can be a lint rule, a type constraint, a test case, or simply a convention in the documentation. Over time, the Harness accumulates more and more rules, and the agent's error rate for known patterns approaches zero.

This is exactly what Martin Fowler calls "Relocating Rigor" — moving the quality gates that humans enforce through code review, experience, and intuition into automated checks. The agent runs freely within the checked boundaries.

Harness = Dataset ​

This perspective comes from Anthropic. Every agent interaction is a training signal:

• What it tried
• What succeeded
• What failed
• What the fix was

These traces are your competitive advantage. They're the data that makes your Harness better over time — not fine-tuning the model, but optimizing the operating system.

Skill Evaluation: Does It Work? ​

Following the skill-creator process, I conducted a quantitative evaluation of this skill. I designed 3 test scenarios, running with-skill and without-skill versions for each:

The with-skill version passed all assertions in every scenario. The without-skill version had the most gaps in the "new project setup" scenario — it didn't know to create AGENTS.md, didn't know how to organize docs/, and couldn't set up the progressive disclosure context architecture.

Of course, a 17% difference isn't enormous. But the key point is: with the skill, the agent's output was consistent and complete; without it, results were hit or miss. For an engineering practice skill, consistency is more valuable than occasional brilliance.

How to Install ​

This skill can be installed via GitHub:

npx skills add 10xChengTu/harness-engineering

After installation, when working in Claude Code, OpenCode, or other agents that support Skills:

• Starting a new project → the skill auto-triggers to guide Harness setup
• Encountering agent quality issues → the skill intervenes for diagnosis when you start complaining
• Proactive inquiry → "Help me improve this project's Harness"

Final Thoughts ​

Harness Engineering is still a very early field. Models are getting stronger, and constraints needed today might be unnecessary tomorrow — so this skill itself follows a core principle: build for deletion.

If you're also doing development with AI Agents, try adding a Harness to your project. Start simple — an AGENTS.md file, a few lint rules, a progress.md. Then observe how the agent's performance changes.

You'll most likely feel the same way I do: It's not that the model isn't good enough — we just haven't given it a good working environment.

All referenced articles and the complete skill source code can be found in the GitHub repository.

✨Article Summary (AI Generated)

HUNT0 is a community-driven launch directory designed for makers and indie hackers. It helps you turn “shipping” into a real event: reserve a launch date, get early feedback through reputation-weighted voting and comments, and discover new products through time-based leaderboards and a filter-first Explore page.

In v1.0.0, the core loop is simple: launch → discover → vote → discuss → recap/reward. With real-time vote sync, a structured submission workflow (Free queue + Premium Launch), and automation like launch reminders and awards, HUNT0 aims to reduce noise and make early discovery feel purposeful.

It all started with a slightly “ugly” sketch: a ladder leaning forward.

That ladder sketch became the HUNT0 logo. It’s a reminder that progress is built rung by rung — and shipping something imperfect beats waiting for perfect.

That’s also where the tagline “Ship Early, Hunt Early” comes from: makers ship early so the community can hunt early — discover, vote, and discuss — helping great products find their first users.

If you’re building in public, launch here. If you’re curious, start hunting.

What is HUNT0? ​

HUNT0 is a community-driven launch directory. It brings shipping and discovery into the same rhythm:

• Reserve a launch date and make shipping a real event
• Get early feedback through voting and comments
• Use leaderboards and Explore to organize “new products” by time and interest — not noise

Launch v1.0.0: what we’ve built ​

v1.0.0 focuses on the core loop first: launch → discover → vote → discuss → recap/reward.

1) Home leaderboards: “what should I check out today?” ​

The home page is organized by time ranges so you can quickly scan what’s worth attention:

• Top Products Launching Today: products launching today (UTC)
• Yesterday / This Week / This Month: recaps with longer windows

Voting state is synchronized in real time across the page: vote on a product anywhere, and every instance updates immediately — no refresh needed.

2) Explore: filter by intent, not luck ​

Explore supports category, tags (up to 10), time range, and full-text search, with paginated results.

Under the same filters, Premium Launch products are prioritized above free launches in ordering — ideal for moments when visibility matters more.

3) Product pages: showcase, visit, and discuss in one place ​

Each product has a dedicated page for deeper context and community interaction:

• Key info and external links (Visit)
• Screenshot gallery and a longer “About this product”
• Reputation-weighted votes and comments
• Leaderboard/award badges (when you rank Top 3 in daily/weekly/monthly awards)

4) Submissions: Free queue + Premium Launch ​

We designed “launch” as a controlled workflow, not just posting a link:

• Free Launch: limited daily capacity (default 10 slots/day) for most launches
• Premium Launch: paid via Stripe Checkout for launches that need stronger visibility

If a premium checkout isn’t completed, the submission stays as a draft in your dashboard and won’t appear publicly until payment succeeds.

Submissions support richer presentation:

• Up to 3 categories
• Up to 10 tags
• Contact/social links (at least one)
• Logo and screenshots for a better product page

Reputation: make contribution count ​

Voting isn’t a flat “one person, one fixed vote”. HUNT0 uses Reputation → Level → Vote Weight:

• Earn reputation by participating (daily visits, voting, commenting, launching)
• Higher levels unlock stronger vote weight
• Leaderboards aggregate weighted votes, reflecting trusted contributors more

It’s both an incentive system and a practical way to reduce noise in early-stage communities.

Reminders & awards: treat launches like events ​

To make launching feel like a real moment, we added automation around it:

• Launch reminder email: sent 1 hour before the UTC launch day begins
• Daily/weekly/monthly awards: automatically compute Top 3 and notify makers (with optional public recap)

Get started ​

• If you’re a maker: go to Submit and reserve your launch date
• If you want to discover: go to Explore and filter by category/tags
• If you want the story: go to About and see where the ladder came from

We’ll keep iterating on discovery, leaderboards, and community incentives. Launch something, hunt something — and tell us what to improve.

Original Link: GPT-4o Image Generation Guide

Turbo0 is a directory of content creator tools where you can find more tools and resources related to image editing at Turbo0.com.

✨Article Summary (AI Generated)

The author has compiled a comprehensive guide to GPT-4o image generation styles, covering a variety of unique artistic styles and application scenarios. It mainly includes:

Classic Art Styles: Ghibli Animation Style、Cyberpunk Style、Watercolor Style、Oil Painting Style、Ukiyo-e Style, etc.

Modern Creative Styles: 3D Chibi Characters、Hand-drawn Sketches、Pixel Art、Low Poly、Hand-drawn Highlight Information Cards, etc.

These styles can be applied to various practical scenarios such as brand design, avatar generation, children's picture books, and product prototypes. The article also shares four secrets to discovering new ways to play: using search engines, social media, professional platforms, and reverse analysis. Through these methods, users can continuously explore and innovate, enhancing their prompt usage skills to create more unique visual effects.

This article provides readers with a systematic reference guide for GPT-4o image generation, serving both as an introductory tutorial and for advanced learning.

Styles ​

Studio Ghibli Style ​

Redraw in the style of Ghibli anime​

Cyberpunk Style ​

A rainy street in a future city, full of neon signs, cyberpunk style.

Chinese Wedding ​

Transform the two people in the photo into chibi 3D characters, dressed in traditional Chinese wedding attire with a red theme, and a "double happiness" paper-cut style background. Clothing requirements: Realistic, the gentleman wears a long robe with a red base decorated with a gold dragon pattern, adorned with a large red flower on the chest representing happiness and prosperity. The lady wears a Xiuhe suit, also red with gold floral patterns and phoenix embroidery, showing elegance and grandeur, complemented by floral hair accessories. Both attires are classic Chinese wedding outfits, symbolizing blessings for a happy marriage. Headwear: The gentleman wears a traditional Chinese scholar's cap in red with gold patterns, topped with exquisite gold details. The lady's headdress is a phoenix crown with red flowers at the center, adorned with gold accents and cascading tassels, rich and classical.

Hand-drawn Doodle Style ​

Transform the image into a hand-drawn doodle style, then create a series of emoji expressions such as sticking out tongue, smiling, frowning, surprised, thinking, and winking from the doodles.

Hand-drawn Illustration Style ​

Create concise, visually structured notes on the topic '{{topic}}'. Notes must fit clearly within a {{orientation}} layout (horizontal/vertical), featuring: - Moderate Font Size: Comfortable readability. - Clear Structure: - Main points highlighted with "background colors" or "wavy underlines~". - Regular notes in standard ink. - Emphasis notes in a different ink color. - Illustrations: - Include relevant sketches or hand-drawn style illustrations. - Allow fountain pen-style doodles or annotations directly on illustrations. - Annotations: - Simulate notes, corrections, and additional quirky doodles resembling spontaneous annotations, using marker pen style. - Incorporate collage-style photo extracts relevant to the topic, annotated or doodled upon. - Language Text Accuracy Constraint (Strict): - When generating text in '{{language}}', abide by recognized dictionaries and standard grammar rules. - For languages like 中文 (Chinese) or others with complex scripts: - Ensure each character or symbol is correct, standard, and used appropriately. - Double-check stroke order, avoid non-existent variants, and verify usage before finalizing the notes. User Settings: - Topic: Child Education - Orientation: Vertical - Language: 中文 - Color Scheme: highlight style. - Illustration Style: Detailed hand-drawn

3D Chibi Style ​

Transform characters in the scene into 3D Chibi style while maintaining the original scene arrangement and costume design. Aspect ratio 2:3

Minecraft Voxel Style ​

Make this in Minecraft voxel style.

Macintosh Computer ​

Create an image in pixel art style of an original Macintosh computer with keyboard. On the screen is the uploaded image opened in MacPaint, converted to black and white. The ratio is 2:3.

3D Chibi Maitreya Buddha ​

3D Chibi style Maitreya Buddha

3D Figurine Style ​

Convert to 3D figurine style.

Studio Portrait Style ​

Stylize the person on the right into the image on the left. The character should slightly turn, similar to the person in the left photo. Wear a black shirt, illuminated by soft studio lighting, with a dark background to create a bokeh effect highlighting details like facial texture or fine lines. Their gaze should reflect calmness, looking into the distance. Portrait photography shot using Sony Alpha A7 III and f/2 lens. Photo realism, 8k resolution. Square format ratio (1:1).

App Icon ​

Create a 3D-style chibi app icon character with a cute, toy-like appearance. The character should have large expressive eyes, a small smile, and detailed, glossy features like a real physical toy. Use a soft, vibrant lighting style to give it a polished, high-quality finish. The character should slightly exceed the app icon’s frame to enhance the 3D effect and playfulness. Style should feel collectible and adorable, like a miniature figure or Nendoroid.

Keyboard Miniature Scene ​

An isometric 3D illustration depicting a miniature player sitting in a mini cockpit under a lifted keyboard keycap, using the inside of the keycap as a glowing screen. It features a slight 3D texture and plasticity, making the whole scene resemble a finely crafted 3D model tailored for gamers.

Miniature World ​

An isometric 3D illustration in a minimalist style, depicting a hidden, extraordinarily serene stress-relief oasis—a Japanese Zen garden—inside an old beige computer tower case (typical late 1990s/early 2000s office style, ATX structure).

External Features: The tower case is classic beige or pale yellow plastic, possibly with a floppy drive slot, CD drive tray, dust-covered ventilation grilles, round power button, and maybe a faded "Property of..." asset tag on the side. Overall, it presents the appearance of a forgotten, vintage piece of office equipment.

Internal Scene: The open side panel of the tower case (or the internal space with the panel removed) is converted into a miniature Zen garden. Most of the space is covered with meticulously raked fine white sand, with mini dark rocks (symbolizing islands) strategically placed among them. A small patch of lush green moss might cover a "rock" corner. There could also be a tiny Tsukubai (Shishi-odoshi) device crafted ingeniously from fine copper wires and electronic components, standing serenely.

Figure: A mini "worker bee" figure, dressed in a wrinkled shirt, perhaps with a loosely tied tie, sits calmly in a corner of the sand garden, holding an extremely tiny wooden rake, gazing intently at the sand patterns, seemingly engaged in a meditative mental exercise.

Details and Atmosphere: Light beams mainly enter through the top ventilation of the case or from the side slits, projecting clear yet soft shadows on the sand and rocks. The light might simulate the cold office fluorescent lighting, but in the garden area, it's tempered by the interior atmosphere to be softer and more tranquil. The scene colors primarily consist of the white sand, dark gray rocks, green moss, and the natural colors of the metal/plastic components in the tower background, forming an elegant, understated contrast, creating an ultimate sense of peace, focus, and escape from reality.

Overall Feel: With a slight 3D texture and some plasticity, it feels like a warm secret hidden beneath the cold facade of technology, akin to a finely crafted desktop diorama. This scene, inside a computer tower that symbolizes work stress and constraints, builds a Zen space representing inner peace and mental freedom, forming a strong visual and emotional contrast. Ideal for modern city dwellers seeking a moment of tranquility, office workers, miniature model and Japanese aesthetic enthusiasts, and those who appreciate digital artwork exploring the relationship between work, life, and the inner world.

Low Poly Style ​

A minimalist 3D island floating in space, low-poly design with pastel colors.

Tourism Visual Notes ​

Please generate an image simulating a hand-written visual note on slightly textured paper (such as cream or light brown) about a tourist location. The image should present a travel journal/collage style, containing the following elements:

• Handwritten in a font that resembles blue or brown ink, including the tourist location's name, geographic location, best visiting season, and one or two catchy slogans or introductions.
• An introduction to several major attractions or features, using numbered lists or bullet points (e.g., list 2-3 specific attractions like "strange rock formations," "ancient legends," "unique plants"), with brief handwritten annotations.
• Highlight or point out particularly recommended spots or activities with red ink or other bright colors (e.g., list 1-2 recommendations).
• Interspersed with simple, doodle-style illustrations related to the features of the tourist location (e.g., think of 1-2 representative drawings based on features like mountain profiles, characteristic plants or animals, iconic buildings, etc.)

Decorated with a few small photos of the location, appearing pasted on from a slightly retro style or Polaroid look. The overall feel should resemble a vividly crafted, engaging personal guide from an enthusiastic tour guide or an experienced traveler.

Hand-Drawn Highlight Information Card ​

Create a hand-drawn style infographic card, ratio 9:16 vertical. The card should have a distinctive theme, with a paper-textured cream or off-white background, embodying a simple, friendly hand-drawn aesthetic. At the top, use prominent red and black contrasting bold script title to capture the visual focus. Text content should adopt Chinese cursive script, with an overall layout divided into 2 to 4 clear sections, each expressing core points in brief, concise Chinese phrases. The script should maintain fluent rhyme, ensuring readability while presenting artistic charm. Sprinkle simple, interesting hand-drawn illustrations or symbols, e.g., figures or symbolic icons, to enhance visual appeal, provoking readers' thoughts and resonance. Maintain balance in the layout, leave ample blank space to ensure the overall design is clean, easily readable and comprehensible.

<h1><span style="color:red">「Cognition」</span> determines the upper limit <span style="color:red">「Circle」</span> determines the opportunity</h1> - You cannot earn money beyond your 「Cognition」, - Nor encounter opportunities beyond your 「Circle」.

Vaporwave Style ​

Redo this image in the Vaporwave style, neon pinks and purples, chrome textures, digital sunset gradients, 1980s retrofuturistic aesthetic...

Pixel Art Style ​

Please generate an 8-bit pixel art style game scene.

Watercolor Style ​

Turn it into Hand-Painted Watercolor.

Innsmouth Shadow Notes ​

Generate an image with an aspect ratio of 2:3 and use English for the text within the image. This image is to simulate a personal notes page created by a reader for the novel The Shadow over Innsmouth. Style: Collage/scrapbook aesthetic, hand-drawn elements mixed with pasted items on a textured paper background (e.g., like a Moleskine notebook or vellum). Please include the following elements: HANDWRITTEN QUOTES: A few classic or impactful English sentences from a novel, written in a clear but handwritten font with a personal touch. CHARACTER DRAWINGS: Simple doodle-style headshots of 2-3 main characters, not necessarily very realistic, but more like quick impressionistic captures. CHARACTER RELATIONSHIPS DIAGRAM: Arrows drawn between the character doodles with short handwritten English text labels describing their relationships (e.g., "Siblings", "Lovers", "Mentor & Student", "Rivals"). PASTED CORNER OF PAGE: A small, realistic-looking piece that simulates a corner torn or cut from an actual novel page (on which some printed English text can be seen) that looks like it was taped or glued to the notes page. (Optional) Annotations: Possibly small handwritten notes or question marks next to quotes or characters. Layout: Elements should be arranged organically, perhaps overlapping slightly, to create the feel of a frequently used personal journal page. OVERALL FEEL: Thought-provoking, analytical, personal, visually appealing.

Oil Painting Style ​

A peaceful European village at sunset, in oil painting style.

Comic Book Style ​

A masked hero jumping from a rooftop, comic book style with bold outlines and dialogue bubbles.

Anime Style ​

Turn it into Anime style.

Ukiyo-e Style ​

Convert this detective movie scene into traditional Japanese Ukiyo-e print style, preserving dramatic shadows and character expressions, adapting to a traditional color palette.

Surreal/Abstract Composition ​

Create a circular image containing a spiral arrangement of 12 objects against a deep space background, including items like crystal hourglass, mechanical butterfly, etc.

Some Scenarios ​

• Brand design and marketing visuals: Logo, product packaging, promotional posters, etc.
• Avatar generation and personal image
• Children's book illustrations
• Product prototype and concept design
• Illustration creation and art design
• Interior design and decoration layout
• Movie storyboard and plot board
• Social media cover art
• Game character design and sketches
• Visual style transformation and image blending
• Educational demonstrations and illustrative explanations

How to Discover New Uses of GPT-4o for Image Generation ​

I recommend checking out Teacher Baoyu's blog post.

Four key techniques: using search engines, social media, the Sora.com platform, and reverse analysis.

These methods help users master the use of prompts, enhance sensitivity and understanding, and create novel visual effects by imitating and blending prompts of different styles. The blog also emphasizes the importance of sharing your success stories, forming a positive feedback loop through sharing and exchanges, jointly exploring more possibilities.

Postscript (More Resource Recommendations) ​

Feel free to self-recommend or suggest GPT-4o drawing resources in the comments section.

• 2025-04-14: Some friends have started collecting such prompts and organizing them into a GitHub repository. Highly recommended to check it out: Awesome GPT-4o Images
• 2025-04-16: Long post demonstrating GPT-4o drawing styles and scenes
• 2025-04-16: A friend organized a Feishu multi-dimensional spreadsheet and open-sourced it into a navigation site

References ​

Some references are directly cited within the article, while others are as follows:

• ChatGPT DeepResearch
• Grok DeeperSearch

✨Article Summary (AI Generated)

In April 2025, Google officially announced a new Agent2Agent (A2A) Protocol at the Cloud Next 2025 event. A2A is an open interoperability protocol designed to break down barriers between different AI agent frameworks and vendors, enabling secure and efficient cross-platform collaboration. Specifically designed for enterprise environments, this protocol addresses data silo issues by standardizing communication between agents, enabling the automation of complex workflows and boosting productivity.

Upon release, A2A received support from over 50 industry-leading enterprises (such as Atlassian, Box, Salesforce, SAP, ServiceNow, MongoDB, etc.). It provides a common framework for AI agents, allowing agents from different vendors or architectures to securely exchange information, coordinate actions, and integrate seamlessly into business operations.

This coalition reflects the industry's shared vision for AI agent interoperability, where in the future, regardless of the underlying technology, AI agents can "converse" and collaborate freely like network services.

Technical Principles ​

Core Architecture ​

An AI agent communication protocol based on HTTP+JSON, primarily consisting of the following modules:

1. Agent Card

   • Location: /.well-known/agent.json
   • Function: A JSON-formatted agent capability manual (including API endpoints, skills, authentication methods)

2. Role Model

   • Server: Provides API interfaces (requiring the implementation of standard methods such as tasks/send)
   • Client: Makes HTTP calls to other agents

3. Task Flow

   • Lifecycle: submitted → working → (input-required) → completed/failed
   • Interaction units:
     • Messages: Composed of multiple types of Parts (text/file/structured data)
     • Artifacts: Structured results produced by tasks

4. Communication Mechanism

   • Basic mode: HTTP + JSON-RPC style interfaces
   • Advanced features:
     • Real-time push: SSE protocol (tasks/sendSubscribe)
     • Asynchronous notifications: Webhook callbacks
     • Multimodal support: Achieved through the Part type

5. UX Negotiation

   • Pre-negotiation of interaction forms between agents (e.g., text/voice/forms)

Basic Framework and Dependencies ​

The A2A protocol itself does not rely on specific AI models or frameworks but is closely related to the trend of autonomous agents driven by large language models (LLM).

The protocol's structure draws upon the concepts of distributed systems and microservices, treating each AI agent as an independent service that communicates through standard interfaces. This means that any LLM-based agent development framework (such as LangChain, LangGraph, Google's Agent Developer Kit ADK, CrewAI, Genkit, etc.) can implement the A2A interface and thereby collaborate with other agents.

Google emphasizes that A2A is adaptable to "opaque" agents—those that do not need to expose internal reasoning processes or memory states. This is crucial for many enterprise-level applications since, in terms of security and compliance, agents tend to interact through clearly defined inputs and outputs rather than sharing internal details.

In summary, A2A provides an application layer protocol specification. Developers can build compliant agents using any technology stack (such as backend in Python, Node.js, etc.), as long as they adhere to the HTTP+JSON interface contract, enabling interconnectivity with other agents.

Protocol Significance: Design Goals and Multi-Agent Collaboration Value ​

Design Intent ​

The introduction of the Agent2Agent protocol stems from the real-world challenges enterprises face when deploying AI agents at scale. As various AI-powered agents (some for customer service, others for office automation, etc.) are introduced in different departments and teams, enabling communication and coordination between agents built by different vendors and frameworks to achieve more complex tasks becomes a significant challenge.

Traditionally, enterprises might need to custom-build integration interfaces or write "glue code" for each pair of interacting agents. This is not only costly but difficult to scale. The design goal of the A2A protocol is to establish a common language for heterogeneous AI agents, allowing them to collaborate out of the box without needing a custom integration layer for each combination. Drawing from its experience in deploying large-scale agent systems internally, Google has abstracted these common challenges, leading the way in forming the A2A as an open standard for the entire industry.

Openness and Neutrality ​

A2A is positioned as an open protocol standard rather than a proprietary Google interface, which is significant. Firstly, being open means that any organization or individual can implement their own A2A agents according to the publicly available specifications, and Google itself has open-sourced the protocol under the Apache 2.0 license on GitHub. More than 50 tech companies, SaaS providers, and consulting organizations participated in the protocol drafting from the start, contributing to its demands and standards.

This multi-party collaboration ensures that A2A has neutrality and universality, avoiding dominance by a single vendor. This is akin to the early days of the internet's HTTP protocol—widely recognized as an open standard fostering interconnectivity between different systems. Similarly, the A2A protocol is also hoped to become the "HTTP between agents," creating an open and unified communication layer for AI agents. Upon its introduction, it was viewed by some as a crucial signal towards AI agent interoperability standardization in the industry.

Complement to MCP ​

Notably, Google positions A2A as a complement rather than a replacement for the Model Context Protocol (MCP) proposed by Anthropic. The MCP protocol primarily addresses how a single agent uses tools and accesses external context, providing a consistent interface for AI models to call APIs and retrieve databases. In contrast, A2A focuses on dialogue and collaboration between agents.

Google metaphorically explains: "If MCP is a wrench that enables agents to use tools, then A2A is the dialogue between mechanics, allowing multiple agents to communicate like a team of mechanics diagnosing problems." In other words, A2A does not compete with MCP; rather, it serves its function—MCP empowers a single agent to connect external tools and data, while A2A connects multiple independent agents into a larger collaborative network. Together, they complement and strengthen a more robust autonomous agent ecosystem.

Enhancing Autonomy and Collaborative Efficiency ​

The value of the A2A protocol in multi-agent systems lies in increasing the ceiling of agent autonomy and collaboration. Through A2A, agents with different capabilities can dynamically form "digital workforce teams" to collaboratively handle complex tasks that a single agent cannot accomplish. For example, a sales AI assistant can directly request a financial AI agent to generate a quote; a customer service chatbot can communicate with a warehouse AI agent about inventory information.

This direct agent linkage saves on human coordination or extra intermediary layers, thereby improving task efficiency and success rate. Research indicates that multi-agent collaboration can significantly increase target completion rates compared to single-agent solutions in enterprise scenarios. Moreover, A2A's standardized approach lowers the marginal cost of introducing new agents—enterprises can add specialized agents into the workflow at any time, and they can immediately "converse" with existing agents without additional development, achieving plug-and-play extensibility.

Security and Governance ​

While emphasizing open collaboration, A2A also focuses on the security and governance concerns important to enterprises. The protocol's design features built-in authentication and authorization mechanisms, with the Agent Card explicitly listing the identity authentication methods required for agent services. Enterprises can control which agents have permission to communicate with each other and exchange which data through unified policy management.

This standardized management approach is more conducive to audit and risk control than having each interface operate independently. Additionally, since A2A only requires sharing the inputs and outputs needed for tasks without involving the internal reasoning process of agents, enterprises can have agents collaborate while protecting proprietary algorithms and data. In the long run, as more enterprises adopt A2A, they can also gain a unified perspective for cross-platform agent management, enabling monitoring and optimization of their entire AI agent "fleet." These standardized, controllable, and manageable features are critical to A2A's implementation in enterprise environments.

Application Scenarios: Automation, Multi-Agent Collaboration, Intelligent Assistants, and Enterprise Communication ​

As a bridge for multi-agent collaboration, the A2A protocol has extensive application potential across numerous business and product scenarios. Below are some typical scenarios and examples to demonstrate the value of A2A:

• Enterprise Process Automation In large enterprises, daily business processes often involve multiple systems and roles. Through A2A, agents with different functions can collaboratively complete end-to-end automated processes. For example, in IT operations scenarios, an agent responsible for asset management can request another agent in charge of procurement to automatically complete tasks such as "ordering a laptop for a new employee."

• Multi-Agent Collaboration A2A's most direct application is enabling multiple AI agents to form collaboration teams to divide and complete complex tasks. In the human resources recruitment process, enterprises may deploy different agents: one responsible for screening resumes, another for scheduling interview times, and another for answering candidates' common questions. Through A2A, these agents can notify each other of progress and share information.

• Intelligent and Personal Assistants Modern intelligent virtual assistants, for personal or workplace use, are becoming increasingly complex. Through the A2A protocol, the intelligent assistant no longer needs to be a single AI model but can be an integrated system that calls on a group of specialized agents behind the scenes. For instance, a personal intelligent assistant planning overseas travel for a user can call a "flight booking agent" to acquire flight options and then call a "trip optimization agent" to plan the travel itinerary, even collaborating with a "translation agent" for local language assistance.

• Enterprise Communication and Collaborative Work In large organizations, different departments may use their AI tools to enhance efficiency. Without a unified standard, these agents operate independently, making it difficult to share information. The A2A protocol allows enterprises to achieve cross-departmental agent collaboration; for example, a sales AI finding a technical issue with a customer can directly notify a customer service AI to follow up through A2A.

• Other Scenarios Beyond the aforementioned typical applications, A2A can also be used in customer service, e-commerce logistics, financial risk control, and many other fields. As AI agents are applied more deeply across industries, any scenario requiring multiple intelligent agents to collaborate can become a point of application for A2A.

Industry Impact: Ecosystem, Competitive Comparison, and Industry Trends ​

Ecosystem Construction ​

The introduction of the A2A protocol has already shown a tangible boosting effect on the AI development ecosystem. First, the involvement of numerous partners indicates that major industry players are working together to forge a unified agent communication standard.

For developers, this means that in the future, when building AI applications, they will be able to conveniently integrate intelligent components from different vendors without worrying about compatibility issues.

Impact on Competitive Landscape ​

As the first open multi-agent communication protocol standard, A2A also places pressure and influence on major AI platform providers. On one hand, Google, by leveraging the open standard to rally industry resources, has solidified its leadership in enterprise AI; on the other hand, other giants like Microsoft, OpenAI, IBM, etc., if they lack a similar standard, will need to consider whether to support A2A to be part of this ecosystem.

In the future, customers may demand AI products to have A2A compatibility to protect their investments. This will prompt more vendors to join the support line to avoid being excluded from the ecosystem.

Meaning for Developers and Enterprises ​

From a developer's perspective, the advent of A2A greatly simplifies the development of multi-agent applications. Previously, achieving interactions between two AI systems using different frameworks required developers to master both interfaces and write adaptation layers; now, as long as both sides implement the A2A interface, they can directly call each other.

This reduces the operational costs and technical risks of deploying AI agents in enterprises, encouraging more traditional IT departments to attempt introducing AI agent collaboration to improve business processes.

Industry Trend Outlook ​

The birth of the A2A protocol aligns with the trend of AI industry moving towards more autonomous and collaborative development. On one hand, the enhanced capabilities of large language models have spawned many applications for autonomous agents, and singular intelligence is gradually unable to meet complex business demands, pushing the architecture from "single agent + tool" to "multi-agent collaboration."

A2A provides the foundational standard necessary for this evolution. On the other hand, enterprises are increasingly demanding data sovereignty and system control—they wish to freely purchase the most suitable AI modules rather than being locked into a single vendor ecosystem. A2A, by allowing open interconnection, meets this decentralized and diversified demand, aligning with the industry's broad trend of open cooperation.

Related Materials: Papers, Blogs, Demos, and Code Repositories ​

Official Releases and Technical Blogs ​

Upon releasing the A2A protocol, the Google team provided comprehensive official documentation and blog posts. The most significant one is "Announcing the Agent2Agent Protocol (A2A)" published on the Google Developers Blog on April 9, 2025.

Technical Documentation and Specifications ​

The complete technical specifications of the A2A protocol have been open-sourced and released on a GitHub repository, which includes the protocol's JSON interface definitions, example codes, and documentation.

Open Source Code Repositories and SDKs ​

Besides specification documentation, the A2A GitHub repository contains sample implementations and development toolkits in multiple programming languages. Developers are welcome to test, reference, and contribute improvements.

Demos and Video Materials ​

To facilitate understanding of A2A's actual effects, Google provides several demo cases. For instance, scenarios demonstrating cross-platform agent collaboration were presented at the launch.

Community Discussions and Analytical Articles ​

The release of A2A has triggered extensive discussions in the AI technical community. Many industry analysts have published insights in blogs and media, providing different perspectives on the significance, application prospects, and potential challenges of the A2A protocol.

Are there any Academic Papers? ​

As of now (April 2025), the A2A protocol is mainly published industrially with no dedicated academic papers detailing its features. However, its concept aligns with research directions in multi-agent systems and distributed AI.

Conclusion ​

The Agent2Agent (A2A) protocol, as an open standard launched by Google in collaboration with industry players, heralds an era of direct dialogue and cooperation between AI agents. Its clear technical framework and enterprise-focused design fill the gap of lacking a universal communication standard in multi-agent systems.

A2A transitions AI agents from isolation to networks: agents with different capabilities can discover, communicate, and coordinate with each other like internet services, achieving autonomous intelligence on a broader scale. For enterprises, it introduces a new paradigm of cross-application AI automation, heralding increased efficiency and innovative possibilities; for developers, it provides standard tools and an ecosystem, significantly lowering the barrier for multi-agent development.

References ​

1. Rao Surapaneni et al., Announcing the Agent2Agent Protocol (A2A)
2. Kevin Ichhpurani, Building the industry’s best agentic AI ecosystem with partners
3. Google Open Source Project, Agent2Agent Protocol – README
4. Chris McKay, Google just Launched Agent2Agent... (Maginative, Apr 2025)
5. Ofweek VicoNet, Google Releases New Agent Protocol A2A... (Reposted from Sina Finance)
6. cnBeta News, Google Launches Agent2Agent Protocol for Cross-Platform AI Agent Connectivity