ANIP 0.24.5: From Protocol to Working Ecosystem
ANIP started as a protocol question:
What should an interface look like when the caller is not a human clicking through a UI, but an agent that can act?
With the 0.24.5 release, ANIP is no longer only a protocol target. It now ships as a working ecosystem: protocol, CLI, code generation, Studio, Registry, signed packages, starter templates, conformance tests, live showcases, Docker images, and a Homebrew install path.
That matters because governed agent execution is not solved by one artifact.
An agent needs to discover what it can do. A product team needs to define what should happen. A developer needs to implement the service boundary. A reviewer needs evidence. A consumer needs a package they can verify and lock. A runtime needs to enforce authority, side effects, approval, denial, and audit behavior.
This release connects those pieces.
What shipped
ANIP 0.24.5 includes:
anip/0.24protocol support- ANIP CLI for validation, package consumption, and service generation
- Homebrew installation for the CLI
- Registry for signed packages and starter templates
- Studio for product/developer design, review, package publishing, template creation, and read-only showcase exploration
- generated service targets for Python, TypeScript, Go, Java, and C#
- HTTP and stdio generated service surfaces across the supported language targets
- package lock and contract signature validation
- protocol conformance packages
- generator conformance across the five supported languages
- scenario-driven execution design and execution scenario validation documentation
- runnable showcase applications
- Docker images for Studio, Registry, CLI-generated services, and showcase stacks
Install the CLI:
brew tap anip-protocol/anip
brew install anip
anip version
Expected output:
anip CLI 0.24.5
ANIP spec anip/0.24
Studio is now a real authoring surface
Studio is not just a demo UI.
It is the place where teams can move from source material into a reviewed ANIP contract:
source material
-> Product Design
-> Developer Design
-> Developer Definition
-> package
-> template
-> generated services
-> validation evidence
That workflow matters because ANIP is intentionally not just developer plumbing. Product and business stakeholders need to agree on what a capability means before developers turn it into a runtime service.
Studio now supports:
- deterministic/manual authoring
- guided assistant mode
- Autopilot mode
- product design review
- developer evidence scaffolds
- capability runtime governance
- input contract formalization
- composed capability metadata
- package and template export
- local publication and registry publication
- read-only hosted showcase browsing
The hosted Studio is available in read-only mode:
Read-only matters. It lets people inspect real showcase projects without mutating the hosted state.
Registry is now the distribution and trust layer
The ANIP Registry is the package surface.
It stores signed ANIP packages and starter templates so consumers can inspect, verify, lock, and generate from known artifacts instead of copying loose JSON around.
The public Registry is live:
registry.anip.dev/registry/packages
The practical flow is:
Studio authors/reviews a contract
-> Registry stores the signed package/template
-> CLI downloads or consumes the package
-> generated service code is produced
-> runtime conformance and scenario validation verify behavior
That separation is deliberate:
- Studio is the authoring and review layer.
- Registry is the trust and distribution layer.
- CLI/codegen is the implementation bridge.
- Runtime services enforce the contract.
- Conformance and scenario validation prove the implementation still matches the contract.
The GTM Agent showcase is the proof point
The GTM Agent showcase is the largest example in this release.
It models a governed revenue-operations agent with service-owned capabilities for pipeline review, forecasting, enrichment, prioritization, routing previews, outreach drafting, approval boundaries, actor-aware visibility, and denial behavior.
The important part is not only that an agent can answer questions.
The important part is that the agent is not carrying the trust boundary in a prompt, skill, or recipe. The service contract owns the governed capability semantics.
The showcase includes:
- a PM/business intent layer
- developer runtime evidence
- generated ANIP services across five languages
- custom backend bundles
- an agent UI
- approval flow
- Metabase BI context
- Docker Compose local run path
- a 490-question behavior bank
- documentation explaining architecture, data, capabilities, generated services, and supported/unsupported questions
The result is a concrete demonstration of the ANIP thesis:
smaller agent surface
+ service-owned capability contract
+ explicit approval/denial/clarification behavior
+ scenario validation
= safer and more reproducible agent execution
Fronting showcases are included
ANIP also ships governed fronting examples.
These show how ANIP can sit in front of existing systems without pretending the backend API disappears.
Current fronting showcases include:
- Jira
- GitHub
- GitLab
- Slack
- Linear
- Notion
- Superset
The point is not to wrap every backend endpoint.
The point is to expose a governed product capability surface in front of native APIs, MCP-style backends, or hybrid integration paths. The backend remains the execution system. ANIP becomes the governed interaction contract.
Why this is more than an incremental release
Many projects reach this shape only after a long sequence of separate releases:
- first the protocol
- then the SDKs
- then the generator
- then the registry
- then the authoring tool
- then the examples
- then conformance
- then packaging
- then deployment docs
ANIP 0.24.5 brings those pieces together early because they need to inform each other.
A protocol without conformance is too easy to interpret differently.
A generator without real showcases is too easy to optimize for toy examples.
A registry without signed packages and templates is just a catalog.
A Studio without validation gates is just a form builder.
A showcase without repeatable generation is just a demo.
The release is important because the loop is now visible:
design
-> review
-> package
-> publish
-> generate
-> run
-> validate
-> inspect
That is the foundation ANIP needs before asking people to evaluate the protocol seriously.
What to try first
If you want to inspect the project:
- Read the docs: anip.dev/docs/intro
- Browse packages: registry.anip.dev/registry/packages
- Open Studio: studio.anip.dev
- Install the CLI:
brew tap anip-protocol/anip
brew install anip
If you want to run a showcase locally, start with the GTM Agent docs:
If you want to understand the core design idea, start here:
The broader point
Agents need more than tool invocation.
They need service-owned contracts that describe what an action means, who may perform it, what it can change, what must be denied, what needs approval, what evidence must be recorded, and how failure should be handled.
That is what ANIP is building.
The 0.24.5 release is the first point where that story is not just described. It is packaged, published, generated, run, and tested.
ANIP is open source: github.com/anip-protocol/anip