From Yellow Pages to Autonomous Agents: Why I’m Building a New Protocol for the Service Economy

Lucas Argate — Sun, 25 Jan 2026 13:56:51 +0000

The Context: A 35-Year-Old Database vs. The Future

By day, I work as a Senior AI Engineer and Tech Lead, building agents and fine-tuning LLMs. But by night, I maintain a system that is the reality for thousands of developers: Legacy Code.

My family runs a service business in Brazil (CARRÊ Redes, specialized in safety net installations). Their system started in Clipper/xBase in 1991. In 2006, I migrated it to C# (.NET Framework 4.5, MVC 4). Today, the data lives in a robust SQL Server, holding decades of customer history, building measurements, and pricing rules.

Recently, Google and OpenAI have been pushing the concept of Agentic AI—interfaces where the AI doesn't just retrieve information but executes transactions (e.g., "Book me a flight," "Buy these shoes").

I wanted to plug my family's legacy system into this new world. I wanted an AI Agent to be able to quote and schedule an installation automatically.

And I hit a wall.

The current protocols for "AI Commerce" (like Google's UCP) are built on a fundamental misunderstanding of how the service economy works. I call it The Retail Fallacy.

The Retail Fallacy in AI Design

Most e-commerce schemas assume you are selling a Product.
A Product has:

A static Price ($50.00).
A static SKU (123-ABC).
A quantitative Stock (50 units).
A generic Shipping cost.

Services are not Products.
If I try to sell a "Safety Net Installation" using a Retail Schema, the AI fails miserably:

Price Hallucinations: The AI sees a "base price" and sells it. But in reality, the price depends on the floor level, the wall type (drywall vs. concrete), and the exact square footage.
Geographic Blindness: In retail, shipping is just a fee. In services, geography is a binary constraint. A technician in City A cannot serve City B, no matter the price.
Inventory is Time: I don't have "units" in stock. I have "time slots" in a calendar.

To fix this, I realized we don't need a better chatbot. We need a better Protocol.

Introducing USP: The Universal Services Protocol

I decided to draft an open standard to bridge the gap between AI Agents and real-world Service Providers. I call it the USP.

It relies on four architectural pillars that replace the standard Retail primitives.

1. Geography as a Constraint (Serviceability Check)

Before an Agent even thinks about quoting, it must handshake on location. We replace "Shipping Calculation" with a Serviceability Endpoint.

The Flow:

Agent sends: { "lat": -22.90, "long": -47.06 }
My Backend (The Legacy Wrapper) checks a Polygon or calculates the driving distance.
Response: TRUE (with a dynamic travel fee) or FALSE.

If FALSE, the conversation ends gracefully. No hallucinations.

2. Price as a Function (Dynamic Quoting)

This is the game-changer for legacy systems. Price is not a variable; it's a function.

The protocol defines that the Provider must expose a Schema of Required Inputs.

Provider says: "To quote this, I need: height, width, and building_type."
Agent: Asks the user for these details.
Agent: POSTs the data to /usp/quote.

The Magic: My backend receives this. It runs a SQL query against data from 1991.
"Oh, this is the Solar Building. We installed there in 1998. The balcony is exactly 12m²."
The API returns a deterministic, signed price. The LLM does zero math. It just conveys the result.

3. Inventory is Time

We treat Time Slots like SKUs.
The API exposes an /availability endpoint.

GET /slots?date=2026-02-10 returns ["09:00", "14:00"].
The Agent can "Soft Lock" a slot (Mutex) while processing the payment to avoid race conditions (double-booking).

4. Contextual Idempotency

Service negotiations are long. A user might ask for a quote today and book it next week.
The USP requires Stateful Quotes. If an Agent quotes a job, it receives a quote_id. That ID is valid for X days. This ensures the price doesn't fluctuate if the user pauses the chat.

The "Legacy Wrapper" Pattern

This is where it gets interesting for us developers. You don't need to rewrite your Monolith.

I am not rewriting the C# MVC 4 application.
I am building a lightweight Sidecar API (using .NET 8 Minimal APIs or Python FastAPI) that sits in front of the SQL Server.

The AI Agent speaks JSON (USP Standard).
The Sidecar speaks SQL (Stored Procedures).

This transforms the "Legacy Debt" into a "Data Moat."
My 30-year-old database is no longer an anchor; it's an Oracle. It has data that no LLM training set has (e.g., specific measurements of local buildings, real-world service times).

Why Open Source?

I am documenting this protocol to be an Open Source standard. Brazil is the perfect sandbox for this—we have a complex service economy and a heavy reliance on conversational commerce (WhatsApp).

If we can build a standard where a Plumber's SQL Database can talk natively to Gemini or ChatGPT, we unlock a massive layer of the economy that is currently invisible to AI.

Call for Contributors

I am currently finalizing the OpenAPI (Swagger) Specification for the USP.

I’m looking for feedback:

Have you tried integrating Services into AI Agents?
How did you handle the "Dynamic Pricing" problem?
Is abstracting this into a Protocol overkill, or necessary?

I’ll be releasing the repo link soon. Let’s build the API for the real world.

follow git repo: https://github.com/LucasArgate/open-usp

Discussion:
What’s the oldest legacy system you’ve had to integrate with a modern API? Let me know in the comments!

DEV Community: Lucas Argate