The missing layer between reasoning and execution

Experience ANIP before reading the whole spec.

Start with something concrete: run a governed agent, inspect a reviewed Studio project, or generate services from a signed package. The protocol details matter, but the first impression should be executable.

5 minutes

Run the GTM Agent Desktop showcase

Ask GTM questions, see bounded answers, approval stops, masking, denial, and audit-oriented outputs without installing Docker.

Open the GTM showcase docs

10-15 minutes

Open ANIP Studio Desktop

Inspect how Product Design and Developer Design become a packageable, verifiable capability contract that agents can consume safely.

Download desktop builds

15 minutes

Generate from the Registry

Browse signed packages and starter templates, verify a package, lock it, and generate a service in Python, TypeScript, Go, Java, or C#.

Browse the Registry

Choose your path

I want to see what ANIP can doShowcases, GTM Agent, and governed fronting apps.I want to build something quicklyStart small, generate a service, then inspect the contract.I want to design capabilities visuallyStudio for PM/business intent, developer evidence, and package review.I want the technical detailsProtocol, lifecycle, transports, trust, and generated runtimes.

MCP exposes tools. It does not replace product workflows.

Today, teams often hand agents raw tools and then teach safe usage with prompt text, skills, recipes, and framework glue. That puts the workflow on the consumer side instead of the service side. The result is fragile: cost is unclear, permissions are implicit, side effects are hidden, approval is bolted on afterward, and failure recovery depends on model behavior.

Tool-first model

user intent → prompt/skill recipe → raw tool call

Agent must infer the workflow the UI used to own

Safety rules live in client prompts or skill files

Prompt injection can redirect or bypass guidance

Service sees an API call, not a governed action

ANIP model

user intent → governed capability → safe outcome

Service exposes the workflow as a contract

Agent gets bounded inputs, authority, and outcomes

Approval, denial, audit, and recovery are service-owned

The interface is designed for agents that act

Framework workflows help, but they do not move the boundary

Agent frameworks, workflow graphs, skills, and recipe repositories can make one app safer. But the rules still live on the consumer side, are not portable across clients, and can force the model to reason through more policy on every request. ANIP moves the governed workflow into the service contract, narrowing the action space so smaller, cheaper models can safely operate bounded capabilities.

The gap

APIs and tool protocols help agents find and call systems. They still do not, by themselves, define the governed meaning of an action.

What APIs and MCP-style tools expose

Available operations or tools
Tool names, descriptions, and input schemas
Transport and authentication shape

What governed agents still need

Which capability matches the business intent?
What does this action cost?
Is it reversible?
Am I authorized to do this?
What are the side effects?
What do I do if I'm blocked?

MCP is valuable because it standardizes tool discovery and invocation. ANIP adds the service-side governed contract for allowed behavior, authority, approvals, denial, audit, and safe recovery.

ANIP aligns product intent with executable capability contracts.

Agent safety is not only a runtime problem. PM, business, security, and developers need to agree on what capabilities mean before those capabilities are exposed to agents. ANIP makes that agreement explicit and verifiable.

Business defines intent

Studio captures scenarios, actors, allowed outcomes, approval boundaries, denial rules, and non-happy paths in business language.

Developers make it enforceable

Developer Design turns that intent into capabilities, inputs, input resolution, scopes, side effects, backend seams, and validation coverage.

Consumers verify what shipped

Registry packages, signatures, locks, receipts, audit, checkpoints, and scenario validation let teams prove the running service matches the reviewed contract.

This is the missing collaboration layer: not just “can the agent call a tool,” but “did the service owner publish the behavior the business approved and the developer implemented?”

How it works

ANIP is not just a tool catalog. A service exposes governed capabilities with authority, input-resolution, approval, failure, audit, and verification semantics.

Discover Contract

Agent fetches the discovery document and manifest to learn the service identity, capabilities, side effects, costs, scopes, supported transports, and trust posture.

curl https://service.example/.well-known/anip

Resolve Intent

Agent maps the user request to a governed capability, then follows declared input-resolution rules: clarify, use defaults, use actor scope, resolve references, or stop.

{
  "capability": "jira.issue.prepare_bug",
  "input": "severity",
  "resolution": { "mode": "closed_values", "on_missing": "clarify" }
}

Check Authority

Agent checks permission posture before acting. The service says what is available, restricted, denied, or grantable for the current actor and purpose.

{
  "available": [{ "capability": "search_flights", "scope_match": "travel.search" }],
  "restricted": [{ "capability": "book_flight", "reason": "missing scope", "grantable_by": "human" }],
  "denied": []
}

Prepare Or Approve

For consequential actions, the service can return a preview or approval request instead of executing. Approval is a contract outcome, not prompt etiquette.

{
  "success": false,
  "failure": {
    "type": "approval_required",
    "approval_request_id": "apr_9c21",
    "preview": { "summary": "Move issue to Done" }
  }
}

Invoke Safely

Agent invokes with a purpose-bound delegation token. The response includes structured success or failure with recovery guidance, cost, and lineage identifiers.

{
  "success": true,
  "invocation_id": "inv_7f3a2b",
  "result": { "flights": [{ "number": "AA100", "price": 420 }] },
  "cost_actual": { "currency": "USD", "amount": 0 }
}

Verify

Every invocation can be audited and checked against signed packages, locks, receipts, and checkpoints. Consumers can verify what ran, under what authority, and against which contract.

curl -X POST https://service.example/anip/audit \
  -H "Authorization: Bearer <token>" \
  -d '{"capability": "search_flights", "limit": 5}'

Build or generate an ANIP service

Start from Studio, a signed Registry package, or code. The toolchain keeps the contract, generated service shape, verifier checks, and runtime behavior aligned.

Studio-first

Design capabilities, scenarios, approvals, and fronting contracts in ANIP Studio, then publish a reviewed package or starter template.

Package-first

Pull a signed package from the Registry, verify it, lock it, and generate a service in Python, TypeScript, Go, Java, or C#.

Code-first

Mount a runtime directly when you already know the capability surface. The runtime handles discovery, delegation, audit, and checkpoints.

Code-first runtime example

The same contract can also be implemented manually when you want direct control over the service code.

Python
TypeScript
Go
Java
C#

app.py
from fastapi import FastAPI
from anip_service import ANIPService, Capability
from anip_fastapi import mount_anip

service = ANIPService(
    service_id="my-service",
    capabilities=[
        Capability(
            name="search_flights",
            description="Search available flights",
            side_effect="read",
            scope=["travel.search"],
            handler=lambda ctx, params: {
                "flights": [{"number": "AA100", "price": 420}]
            },
        ),
    ],
    authenticate=lambda bearer: {
        "demo-key": "human:[email protected]"
    }.get(bearer),
)

app = FastAPI()
mount_anip(app, service)

app.ts
import { Hono } from "hono";
import { createANIPService, defineCapability } from "@anip-dev/service";
import { mountAnip } from "@anip-dev/hono";

const searchFlights = defineCapability({
  name: "search_flights",
  description: "Search available flights",
  sideEffect: "read",
  scope: ["travel.search"],
  handler: async (ctx, params) => ({
    flights: [{ number: "AA100", price: 420 }],
  }),
});

const service = createANIPService({
  serviceId: "my-service",
  capabilities: [searchFlights],
  trust: "signed",
  authenticate: (bearer) =>
    ({ "demo-key": "human:[email protected]" })[bearer] ?? null,
});

const app = new Hono();
mountAnip(app, service);

main.go
package main

import (
    "net/http"
    "github.com/anip-protocol/anip/packages/go/service"
    "github.com/anip-protocol/anip/packages/go/httpapi"
)

func main() {
    svc, _ := service.New(service.Config{
        ServiceID:    "my-service",
        Capabilities: []service.CapabilityDef{searchFlights()},
        Storage:      "sqlite:///anip.db",
        Trust:        "signed",
        Authenticate: func(bearer string) *string {
            keys := map[string]string{
                "demo-key": "human:[email protected]",
            }
            if p, ok := keys[bearer]; ok { return &p }
            return nil
        },
    })
    defer svc.Shutdown()
    svc.Start()

    mux := http.NewServeMux()
    httpapi.MountANIP(mux, svc)
    http.ListenAndServe(":9100", mux)
}

Application.java
@SpringBootApplication
public class Application {
    @Bean
    public ANIPService anipService() {
        return new ANIPService(new ServiceConfig()
            .setServiceId("my-service")
            .setCapabilities(List.of(
                SearchFlightsCapability.create()
            ))
            .setStorage("sqlite:///anip.db")
            .setTrust("signed")
            .setAuthenticate(bearer -> {
                Map<String, String> keys = Map.of(
                    "demo-key", "human:[email protected]"
                );
                return Optional.ofNullable(keys.get(bearer));
            }));
    }

    @Bean
    public AnipController anipController(ANIPService s) {
        return new AnipController(s);
    }
}

Program.cs
var builder = WebApplication.CreateBuilder(args);

var service = new AnipService(new ServiceConfig {
    ServiceId = "my-service",
    Capabilities = [SearchFlightsCapability.Create()],
    Storage = "sqlite:///anip.db",
    Trust = "signed",
    Authenticate = bearer => {
        var keys = new Dictionary<string, string> {
            ["demo-key"] = "human:[email protected]"
        };
        return keys.TryGetValue(bearer, out var p) ? p : null;
    }
});

builder.Services.AddAnip(service);
var app = builder.Build();
app.MapControllers();
app.Run();

Same result in every language: governed discovery, signed manifest, delegation-based auth, structured failures, approval/audit surfaces, and verifiable checkpoints.

anip verify --package-bundle ./service.anip-package.json
anip generate --package-bundle ./service.anip-package.json --target typescript --output ./generated/service

Follow the quickstart

What ships today

ANIP is not a spec waiting for implementations. It ships runtimes, Studio, Registry, CLI tooling, package workflows, and showcase systems.

5 runtimes

TypeScript, Python, Java, Go, and C#. Each runtime handles the full protocol — discovery, delegation, audit, checkpoints — so you only write capabilities.

ANIP CLI

Generate services, verify definitions and packages, publish package revisions, emit locks, and create integration templates from the command line.

ANIP Registry

Signed packages, templates, locks, contract signatures, tooling metadata, download tracking, and consumer-facing package guidance. Browse packages.

ANIP Studio

Guided and Autopilot project design, fronting flows, source docs, product/developer revisions, diagnostics, package publication, and template export.

Transports and interfaces

HTTP, stdio JSON-RPC, and gRPC support, plus generated inbound surfaces such as OpenAPI/REST, GraphQL, and MCP compatibility where useful.

Conformance and validation

Runtime conformance, generator conformance, package verification, scenario-driven execution design, and execution scenario validation.

GTM Agent showcase

A full GTM agent system with generated ANIP services in all five languages, approval flows, question banks, local Docker stacks, and Metabase verification.

Fronting showcases

Governed fronting packages for Jira, GitHub, GitLab, Slack, Linear, Notion, and Superset-style analytics. The point is capabilities, not raw API mimicry.

Starter templates

Reusable project templates for Studio so teams can start from reviewed structures instead of recreating every service or fronting project from scratch.

How ANIP compares

ANIP is not a replacement for HTTP, gRPC, or MCP. It adds a governed execution contract above transport, tool discovery, and tool-call schemas.

Capability	REST / OpenAPI	MCP	ANIP
Tool / endpoint discovery	Endpoint catalog	Tool catalog	Signed capability contract
Side-effect posture	Usually inferred or documented in prose	Advisory hints clients may use	Contract posture used by permission, approval, audit, and verification
Permission discovery before invoke	Usually learn by calling and failing	Usually host/server-specific policy	Portable available / restricted / denied posture before execution
Scoped delegation and purpose limits	External auth; execution purpose is app-defined	Transport auth; execution purpose is not a portable contract	Purpose-bound delegation chains with scope and budget narrowing
Input resolution and clarification	Validation only; clarification is app logic	Tool schema and client/server behavior	Declared clarify / default / actor-scope / resolver behavior
Approval and preview outcomes	Possible, but custom	Possible, but host/tool-specific	Standard approval_required outcome with grant continuation
Cost declaration + actual cost	Custom if needed	No portable cost contract	Declared estimate before execution + actual cost after execution
Structured failure + recovery	Status codes plus custom error bodies	Tool errors plus custom payloads	Portable failure type, recovery action, grantability, and retry guidance
Audit logging	Custom logs	Host/server logs	Protocol audit trail with retention, classification, lineage, and authority context
Package verification and execution evidence	External supply-chain tooling	Implementation-specific	Signed packages, locks, receipts, JWKS, and tamper-evident checkpoints