Absorb vs building it yourself
The first wrapper is a short project. The tenth is a program. The cost is not the protocol; it is field filtering that survives irregular specifications, credential handling, authorization workflow, audit, and every specification that changes beneath you.
Side by side
| In-house wrappers | Absorb | |
|---|---|---|
| First API | A short build, and it demonstrates well | A single session, including the review document |
| Tenth API | Ten codebases and ten deployments | Ten policies, one runtime, optionally one process |
| Messy specs | Each irregularity becomes a production defect | Unions, envelopes, form bodies, RPC-style paths and Swagger 2.0 are handled, validated against 4,130 public specifications |
| Response filtering | Written by hand per endpoint, and drifts silently | Derived from the specification, with undocumented fields removed by default |
| Credentials | Typically an environment variable per wrapper | One credential model: bearer, basic, header, query, OAuth client credentials or token exchange |
| Approvals | A separate project | Configuration, with Slack, ServiceNow, a signed webhook and an administrative queue |
| Audit and metrics | Whatever each service happens to log | One record per call, with export and Prometheus metrics included |
| Spec drift | Discovered by an agent in production | Detected by probe in your pipeline, and measured in production |
| Security review | Repeated for every wrapper | A single policy format, reviewed once and reused |
The elements that are routinely underestimated
Filtering that holds under pressure
Removing a top-level field is straightforward. Removing it from within a union, an envelope or an undocumented object is where wrappers leak.
Specifications that resist
Query strings in path keys, form-encoded bodies, external references, malformed YAML and deep pointers. Each of these was addressed in response to a real specification, not a hypothetical one.
Evidence on demand
When an auditor asks which agent called which operation on a given date, the answer should be a file you hand over, not an investigation.
Absorb is a single static binary whose only dependencies are the Go standard library and a YAML parser, so adoption means operating one process rather than onboarding a platform.
When an in-house build is the right choice
With one small internal API, no personal data in responses, no write operations and no audit requirement, a small in-house component is the right answer. The calculation changes when a second team requires the same capability, or when an auditor asks who authorized a given call.
Questions
We already built one. Is that work wasted?
No. The policy implicit in your code becomes an explicit policy file, and the agent side is unchanged because both speak the same protocol.
How long does a migration take?
Typically one session per API: compile the specification, adjust the policy until the report matches what your wrapper permitted, then repoint the agent at the new endpoint.
What do we still own?
The policies and the deployment. Absorb runs in your environment, so the runtime, the data and the credentials remain with you.
Other comparisons
Absorb vs OpenAPI-to-MCP wrappers
Publishing an entire specification as tools, against compiling a policy into a defined allowlist.
Absorb vs API gateways
Forwarding the requests you receive, against determining which operations exist for an agent.
Absorb vs MCP gateways
Governing the MCP servers you already run, against compiling a governed server from your own API.
Compile your own API and assess the result
Send a specification. We will show the tools it produces, the operations it withholds, and the document your security function would review.