AI brought side projects back: building an agent communication protocol

I saw a LinkedIn post last week that really got me thinking: AI has made it possible for us to return to having side projects to learn and test ideas.

In my case, this became my favorite “second shift” — those extra hours at night and on Saturday mornings. I’ve always been a fan of this.

Last year, along with Marcell and Farinazzo, we built PromptMetrics during the Lovable Shipped competition, and I shared every step of it. It was an intense 0-to-1 experience that showed me the power of rapid execution.

This year, I decided my focus would be deeper technical learning. I wanted to get my hands dirty with real implementation, understand service architecture, and finally master Python.

That’s how the ASAP protocol was born — a communication protocol for AI agents (think A2A, but better 😜).

What started as a curiosity about how agents talk to each other turned into a full open-source project that just hit version 2.1.1.

In this article, I’m opening up the project’s “brain,” the vibe coding workflow I used, and how I organized the architecture to go from a nerd sketch to a functional agent marketplace.

The problem: why another protocol?

The idea came up while chatting with my team at Pipefy, about the deficiencies in protocols like A2A and the common complaints in dev forums.

The challenge isn’t just communication; it’s standardization, trust, and discovery.

I wanted something lightweight and focused on performance. I wanted to see how gRPC and FastAPI could work together to create a transport layer that wouldn’t choke on latency.

Vibe coding: 85% AI and 15% Human

People often ask me how I maintain this pace. The truth is: the development was 85% assisted by Cursor.

But don’t be fooled — the 15% manual work is where the architectural decisions and trade-offs happen.

My current setup is what I call “model orchestration”:

• Planning: Claude Opus 4.6 (in Cursor’s MAX Mode with high reasoning).
• Development: Composer 1.5 and Cursor’s auto mode for the heavy lifting.
• Technical Review: I don’t trust just one model. I run the code through GPT-5.2 Codex, Gemini 3.1 Pro, and Kimi K2.5 to find logic bugs or bottlenecks.

AI doesn’t replace the architect; it empowers them. I focus on the “what” and the “why,” while the AI handles the “how.”

The project’s “brain”: Context Engineering in practice

To avoid getting lost in the chaos of AI generating thousands of lines of code, I organized my repository so the AI could understand the full product and engineering context.

The .cursor/ folder is the command center:

• product-specs: where I keep ADRs (Architecture Decision Records) and PRDs for each version.
• dev-planning: where sprints are broken down into granular tasks so the AI doesn’t “hallucinate” or wander off during the process.
• skills, rules, and commands: specialized prompts that teach the AI to review security or code quality specifically for ASAP standards.

This structure allows me to delegate execution to the AI while maintaining total governance over the system design.

From foundation to marketplace: the roadmap

ASAP’s evolution was planned in clear milestones to ensure each release delivered real value. As we built it, the scope grew as new ideas popped up 🤯.

v1.0: Technical Foundation

Focus on protocol stability. We defined how messages would be structured and how state would be persisted using a hybrid strategy between SQLite and flexible storage interfaces.

v1.2: Verified Identity

Focus on security. I implemented Ed25519 signatures to ensure one agent couldn’t impersonate another. We used the JCS standard for canonicalization and strict verification.

v2.0: Marketplace Launch

This milestone transformed the protocol into an economic layer. I created a web interface where any dev can register their agent through a simple IssueOps flow on GitHub. Our Lite Registry runs on GitHub Pages to keep infrastructure costs at zero.

v2.1: Ecosystem & Integrations

Those building agents can now find and invoke marketplace agents in minutes without manual integrations. I focused on native integrations with LangChain, OpenClaw, LlamaIndex, SmolAgents, and support for MCPs (Model Context Protocol).

Categories and revocation keep the catalog reliable and easy to navigate. With the package on PyPI, experimenting is just a pip install away.

What’s ahead: v2.2 ➔ v3.0

Currently, I’m focused on closing v2.2, which centers on scale and ease of adoption:

• Auto-registration: Implementing GitHub IssueOps so new agents are listed without manual PRs.
• Agent builder: A visual interface for any developer to configure their agent’s capabilities and export a marketplace-ready manifest.

In v3.0, we hit the ultimate goal: the economy layer. This includes the Verified Badge for high-reputation agents, a credit system for automated usage billing, and real-time SLA monitoring.

The protocol and registry will remain open. The value lies in visibility, trust, and liquidity between agents.

Learning is the only guaranteed ROI

At the end of the day, building in public remains the best “university” I’ve ever attended.

I learned to create an end-to-end protocol, dealt with cryptographic security, built a design system from scratch, and published packages on PyPI that real people can use.

Even if ASAP doesn’t become the industry standard, my gain is understanding exactly how everything works under the hood and the rationale behind the build.

If you want to critique my architecture, open an issue, or star the repo — the door is open. It’s open source; come contribute. That’s how many of the tools we use today started.

It’s time to build, LFG.