The Problem With GET and POST
When a browser loads a page or an app talks to an API, it sends HTTP requests to a server, and each request includes a verb that tells the server what kind of operation this is. GET means “give me something”, POST means “here’s data, do something with it”, DELETE means “remove this.”
These verbs aren’t just labels — they carry a contract that every layer of infrastructure in between uses to make real decisions. GET methods are generally considered “safe”, meaning they don’t change anything on the server, so proxies cache them, retry logic handles them without caution, and audit systems classify them as read operations. POST is not, because it might create a record, trigger a payment, or kick off a workflow, so if a POST request fails mid-transit and you retry it, you might execute the operation twice, and everything in the path treads accordingly.
What travels with the request also depends on the verb. GET carries its parameters in the URL, so a search for active Acme contracts looks like this:
GET /contracts?client=acme&status=activeRead-only, no side effects, fits in the URL, and every layer of infrastructure knows how to handle it.
Now consider what an AI agent actually needs to ask when it’s researching before it acts:
POST /search
{
"query": "obligations with penalty clauses expiring before Q3",
"filters": {
"date_range": "2026-01-01/2026-09-30",
"document_types": ["contracts", "amendments", "side_letters"],
"counterparties": ["acme-corp", "beta-industries"]
},
"semantic_similarity_threshold": 0.78,
"top_k": 25,
"rerank_by": "recency",
"session_context": "legal review, Q2 obligations audit"
}That is a read operation and nothing is changing, but this body doesn’t fit in a URL so it can’t be a GET, and it becomes a POST even though it shouldn’t be, so every system in the path treats it as a potential state change, caches skip it, retry logic gets cautious, and every permission layer in the stack flags it as a write operation. The agent is asking a question, but the infrastructure thinks it might be signing a contract. QUERY fixes this by combining the safe behaviour of GET with the structured body of POST — safe and idempotent like GET, expressive like POST, and with a contract every intermediary can actually enforce.
Three Problems It Solves at Once
URLs have a size limit. A semantic search query carrying embedding vectors, filter conditions, and ranking parameters doesn’t fit in a URL and never did, so teams have been reaching for POST not because it was the right verb but because it was the only one that could carry the payload.
POST was never meant to be read-only. Every proxy, gateway, audit log, and permission layer in your stack treats POST with caution because it might be mutating state, so when your agent is in a retrieval phase and reading context before it acts, the infrastructure thinks it’s doing something risky even though it isn’t and can’t tell the difference. This is not a theoretical concern — it’s why agent permission models built on top of HTTP have a gap between what the tool schema says and what the transport actually enforces.
Caching breaks at exactly the wrong moment. GET responses can be cached by intermediaries but POST responses can’t. Consider an internal knowledge agent rolled out across an organisation — hundreds of employees asking it about HR policies, pricing rules, or technical documentation throughout the day. The underlying documents don’t change hour to hour, and many of those queries are structurally similar, but because the agent uses POST to send them, every single one triggers a fresh round-trip to the knowledge base. With QUERY, those responses can be cached at the infrastructure level, so the fiftieth person asking about the travel policy gets the answer in milliseconds rather than waiting for a new database call. At scale, that difference is measurable in both latency and cost.
Why This Changes the Agent Safety Conversation
Human-in-the-loop gates, approval workflows, permission taxonomies — every AI agent safety model, however it’s assembled, rests on one underlying distinction: is the agent gathering information or changing something?
Get that distinction right and you can calibrate when to require approval and when to let the agent run autonomously, but without it your permission model is working from inference rather than fact.
The Model Context Protocol already encodes this in its tool schema, where tools declare whether they’re read-only or mutating and orchestration layers use that to decide whether a human needs to sign off. That’s the right abstraction, but the problem is that the HTTP transport underneath couldn’t carry the same signal until now — so the safety model held at the application layer and leaked at the protocol layer.
With QUERY, the method itself tells every layer of infrastructure what kind of operation this is, so your permission system doesn’t need to inspect the request body or rely on application metadata because the intent is in the verb.
Read operations: GET and QUERY. Agent can proceed autonomously. State changes: POST, PATCH, DELETE. Route to approval.
That boundary is now enforceable at the protocol layer, not just the application layer, and for enterprise teams running agents in production that’s a meaningful shift from a permission model that depends on correct configuration to one that the infrastructure itself enforces.
The Takeaway
Most teams building with AI agents today are working with the same protocol mismatch that HTTP has had since POST became the default for anything that didn’t fit in a URL. QUERY doesn’t change the fundamentals of how you build, but it gives you a cleaner foundation — one where the read/write distinction is enforced at the transport layer, not just documented in your application code.
The practical question is whether your current agent architecture has that distinction enforced below the application layer at all. For many teams the honest answer is that it isn’t, and that’s a reasonable position given that the alternative hasn’t existed until now.
That said, early adoption deserves some caution. Not every proxy, gateway, or intermediary in the ecosystem recognises QUERY yet, and sending it through infrastructure that doesn’t recognise it can result in requests being rejected or mishandled. For critical production systems running on mature third-party infrastructure, that’s a real risk worth assessing before committing. The natural starting point is systems being built from scratch to support agentic workflows — where you control enough of the stack to not depend on intermediaries that haven’t updated yet. Start with internal endpoints where you own both sides of the call, validate the pattern, and let external-facing adoption follow once you have confidence in the infrastructure.
What This Means for Your Team
Zartis works with enterprise engineering teams on agentic architecture, including the tool governance, permission models, and retrieval infrastructure that production agents depend on. If your safety model is sitting entirely at the application layer right now, that’s the gap worth closing first. Talk to us about an AI-Enabled SDLC review and we’ll map your current architecture against the transport, protocol, and permission layers where most production risk actually lives.
Author
Yannis Kotsinos is a Software Engineer at Zartis, where he serves as the company’s AI Navigator, a role recognising his deep hands-on expertise in applied AI. Over the past two years he has worked almost exclusively with agentic pipelines, integrating them into day-to-day engineering workflows. He is an Anthropic-certified Claude Code professional, and has contributed to numerous internal workshops on Claude Code and Cowork, leading selected sessions and acting as technical backup on others, providing in-depth support whenever teams needed to go deeper.
