Como estou preparando um legado de 1991 (Clipper/SQL) para a Era dos Agentes de IA: A Proposta do USP
O Contexto: Do Clipper ao GPT-OSS/Gemini
Eu atuo hoje como Tech Lead e Senior AI Engineer na Sinky, trabalhando na crista da onda com LLMs e agentes autônomos. Mas, paralelamente, tenho um "pet project" que é a realidade de muitos devs brasileiros: o sistema da empresa da minha família, a CARRÊ Redes.
Estamos falando de um negócio que opera desde os anos 90. O sistema original era em Clipper/xBase. Em 2006, migrei para .NET (C# Framework 4.5, MVC 4) e hoje os dados residem em um SQL Server parrudo, contendo histórico de clientes, medidas de prédios e orçamentos desde 1991.
Recentemente, o Google começou a falar forte sobre o UCP (Universal Commerce Protocol) e Agentic Web. A promessa é linda: permitir que IAs não apenas busquem informações, mas realizem transações (compras) diretamente.
Fui estudar a documentação do UCP para ver como plugar a empresa da família nisso. E bati de frente com um muro arquitetural.
O Problema: A "Falácia do Varejo" na IA
A maioria dos protocolos atuais de IA (incluindo as specs de plugins do OpenAI e o UCP do Google) assume que o mundo é um grande E-commerce de Varejo.
Eles esperam primitivas como:
Product ID(SKU estático)Price(Float constante)Stock(Integer)Shipping(Logística genérica)
Para quem vende tênis ou iPhone, funciona. Para quem vende Serviços (instalação, manutenção, consultoria, saúde), isso é inútil.
Se eu tentar vender uma "Instalação de Rede de Proteção" como um produto de varejo para uma IA, o resultado será catastrófico:
- Alucinação de Preço: A IA vai inventar um preço médio, ignorando que o 5º andar custa mais que o térreo, ou que drywall exige bucha especial.
- Erro de Roteamento: A IA vai vender o serviço para um cliente a 500km de distância, porque o "frete" no varejo é só uma taxa, mas em serviço é uma inviabilidade técnica.
- Conflito de Concorrência (Race Condition): Serviços dependem de agenda. "Estoque 1" não significa nada se o técnico só pode na terça às 10h.
A Solução Proposta: Universal Services Protocol (USP)
Como não encontrei um padrão que resolvesse o problema de Service-First AI, decidi desenhar um manifesto e uma especificação técnica. A ideia não é criar um "SaaS", mas um padrão de interoperabilidade (JSON/REST) para que sistemas legados exponham suas regras de negócio para Agentes de IA.
Chamei de USP (Universal Services Protocol).
A arquitetura se baseia em expor 4 endpoints críticos que substituem a lógica de varejo:
1. Serviceability Check (Geofence > Shipping)
Em vez de calcular frete, o sistema deve responder uma pergunta booleana baseada em polígonos.
- Request:
{ "lat": -22.90, "long": -47.06 } - Legacy Logic: O backend faz um point-in-polygon check no banco ou calcula a distância rodoviária real.
- Response:
{"serviceable": true, "surcharge": 45.00}
Isso impede que o Agente sequer comece uma negociação fora da área de atuação.
2. Dynamic Quoting (Function > Constant)
Aqui está o pulo do gato para quem tem legado. O preço é uma função.
O protocolo define que a IA deve atuar apenas como "coletora de inputs".
- A API expõe um schema: "Preciso de
altura,larguraetipo_parede". - O Agente (LLM) conversa com o usuário para preencher esse JSON.
- O Agente faz um POST para o endpoint
/quote. - O seu Backend (C#, Java, Node) roda a regra de negócio complexa. No meu caso, consulto no SQL Server se já instalamos naquele prédio em 1998. Se sim, tenho as medidas exatas.
- A API devolve um preço assinado e imutável por X dias.
Isso tira a responsabilidade de cálculo da LLM (que é péssima em matemática e lógica determinística) e devolve para o sistema (que é perfeito nisso).
3. Inventory as Time (Slots > Integers)
O estoque de serviço é perecível. Um slot de agenda não vendido hoje deixa de existir amanhã.
O USP propõe um endpoint padronizado de /availability que retorna TimeSlots livres. O Agente deve ser capaz de fazer um "Soft Lock" (reserva temporária de 5 min) enquanto processa o pagamento, garantindo idempotência e evitando double-booking.
O Padrão "Legacy Wrapper"
O ponto mais interessante para nós, devs, é que não precisamos reescrever o legado.
Para a CARRÊ Redes, não vou mexer no monolito MVC 4.
Estou subindo uma camada de API Gateway (Sidecar) — provavelmente em .NET 8 Minimal API ou Python FastAPI — que traduz as requisições do protocolo USP para Stored Procedures do meu SQL Server antigo.
O Agente de IA do futuro, quando quiser contratar um serviço, vai bater nesse endpoint padronizado. Ele não sabe que por trás tem um banco de 30 anos. Ele só vê um JSON limpo.
Isso valoriza o "Data Gravity" que empresas antigas têm. O sistema legado deixa de ser dívida técnica e vira um oráculo de dados proprietários que a IA não tem.
Próximos Passos e Open Source
Estou formalizando essa spec (Swagger/OpenAPI) e pretendo abrir como Open Source focado no mercado brasileiro (que é caótico e complexo, o melhor lugar para testar edge cases).
Acredito que a próxima grande onda não é apenas "Chatbots de Atendimento" (RAG), mas Agentes Transacionais. E para isso acontecer em Serviços, precisamos falar a mesma língua.
Se alguém aqui já trabalhou com integração de serviços complexos (agendamento/orçamento dinâmico) em APIs e quiser dar pitaco na estrutura do JSON, estou montando o repositório.
O que acham? Faz sentido abstrair essa complexidade num protocolo ou estou "over-engineering" o problema?