AI brought side projects back: building an agent communication protocol

I recently saw a LinkedIn post 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 second shift — those extra hours at night and on Sunday mornings.

I’ve always been a fan of this.

Last year, along with friends, we built PromptMetrics during the Lovable Shipped competition, reaching top 15 globally in one of the phases (and finishing 25th overall out of 5,800 teams).

It was an intense 0 to 1 experience that showed me the power of rapid execution with AI.

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 dig into a new language, and I found myself in 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.

We’re at v2.5.4, production-ready enough that the interesting question shifted from “can agents talk?” to “can a stranger install, wire, and ship in an afternoon?”

In this article, I’m opening up the project’s “brain,” the harness 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.

My workflow: 80% AI and 20% human

The development was ~80% assisted by Cursor Cloud Agents, but don’t be fooled, the 20% manual work is where the architectural decisions and trade-offs happen.

My current setup:

• Planning: Fable or GPT 5.6 or Astra (in MAX Mode with high reasoning).
• Development: Composer 2.5 and Cursor’s Grok 4.x for the heavy lifting.
• Technical review: I don’t trust just one model. I run the code through other models to find logic bugs or bottlenecks.

I focus on the “what” and the “why,” while the model handles the “how.”

The bigger change isn’t only which model I pick on a given night.

It’s that the repo now forces governance before generation: AGENTS.md as a context map, always-on rules for security and commits, skills for security and code-quality review, and a pre-push CI gate I actually run locally.

The project’s “brain”: context engineering in practice

To keep AI from generating thousands of clever lines in the wrong direction, I stopped treating the repo as “code + vibes” and started treating it as a product OS.

The command center is still agent-oriented, but the map changed:

• product/prd and product/decision-records: PRDs and ADRs for each release train (the source of truth for scope).
• engineering/tasks: sprints broken into granular packs so the agent can’t wander mid-flight.
• AGENTS.md + cursor/README.md: a context map and precedence order (user rules → always-on rules → skills → docs).
• rules and skills: constraints and deep workflows — security review, clean code, rate-limit testing, frontend standards.

I still delegate execution. I just stopped delegating judgment.

If the AI can’t point to a PRD, an ADR or a task pack, it doesn’t get to invent a feature.

The tree still looks nerdy. That’s the point. Context engineering stopped being a slide and became how the project ships.

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

Protocol stability, message structure and hybrid persistence (SQLite + flexible storage interfaces).

v1.2: Verified identity

Ed25519 signatures + JCS canonicalization so one agent cannot impersonate another.

v2.0: Marketplace launch

This turned the protocol into an economic layer. 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 zero while we validate the idea.

v2.1: Ecosystem and integrations

Native adapters for LangChain, OpenClaw, LlamaIndex, SmolAgents, and support for MCPs. Categories, revocation and the package on PyPI made discovery and installation trivial.

v2.5.4: where we are now

The marketplace is live at asap-protocol.com.

We added the MCP Auth Bridge (scoped native tools via Agent JWTs), a TypeScript SDK, OpenAPI connectors, edge-AI discovery filters and a compliance harness.

What’s ahead

v2.5.5

The formal specification, introspection and cross-protocol interop.

Agent builder

A visual interface for any developer to configure their agent’s capabilities and export a marketplace-ready manifest.

Some data is real and some is mocked. I’m still working on integrating this journey with the marketplace.

v3.0

The economy layer: Verified Badge, a credit system for 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.