Publishing Agents: From Notebook to Enterprise Registry

Most agents die in a notebook. The ones that survive become services: versioned, documented, discoverable, authenticated — things another team can call without reading your source. This is the plumbing that turns “my agent” into “our platform”, using the Microsoft Agent Framework’s hosting and discovery primitives as the concrete example.

Sources: Microsoft Agent Framework overview, A2A hosting (.NET), A2A server (Python), A2A integration & discovery, hosting options.

Stage 1: give the agent a contract, not a script

A notebook prototype couples three things that must separate:

• The agent logic — model client, tools, instructions, workflows.
• The transport — HTTP, JSON-RPC, queues.
• The metadata — name, description, capabilities, auth requirements.

The Microsoft Agent Framework (open source for .NET, Python and Go; the direct successor to Semantic Kernel and AutoGen) bakes this separation in. Its four pillars — Agents (LLM + tools + MCP servers), Harness Agent (planning, compaction, memory, approvals, observability), Workflows (functional and graph-based), and Integrations — mean the agent object you register is transport-agnostic. Install is one line: pip install agent-framework or dotnet add package Microsoft.Agents.AI.Foundry.

That transport-agnosticism is what makes “publishing” a config step instead of a rewrite.

Stage 2: pick a hosting shape

The framework’s hosting options table is the decision matrix:

Hosting	When it fits
A2A server	Cross-org/cross-team agent-to-agent calling — the default “publish” story
OpenAI-compatible endpoint	Reuse existing OpenAI client tooling and gateways
Azure Functions (durable)	Event-driven, scale-to-zero, long-running orchestration
AG-UI	Streaming UI protocol for front ends

The general pattern: keep the agent as a plain object, then expose it. In .NET that’s AddA2AServer(...) plus MapA2AHttpJson (or MapA2AJsonRpc) and MapWellKnownAgentCard(...); in Python the agent-framework-a2a package provides an A2AExecutor that adapts any agent to an A2A server.

Stage 3: publish an agent card (your agent’s API contract)

A2A’s core artifact is the agent card — a machine-readable manifest describing what the agent does, which languages it speaks, what auth it expects, and its skills. Once hosted, the card is discoverable at a well-known URI (/.well-known/agent.json or /.well-known/agent-card.json, depending on implementation).

Think of it as OpenAPI for agents. Consumers get:

• Name, description, version — so a catalog can index it.
• Skills/capabilities — so orchestrators know when to route work to it.
• Auth requirements — so clients can attach the right credentials before calling.
• Endpoint — where the A2A traffic actually goes.

Writing this card well is 80% of adoption: an agent nobody can find and understand is an agent nobody calls.

Stage 4: register it where teams look

Direct card fetching is fine for one integration; a platform needs catalog-based discovery. The framework supports exactly that — agentCard.AsAIAgent() turns a card from a catalog/registry into a usable client — alongside the two other access paths: fetching the well-known card directly, or constructing an A2AClient against a known URL.

In practice your registry entry is the card plus your internal metadata: owner, SLO, data classification, cost profile, approval status. The registry is a discovery layer, not a trust layer — it points to the card; auth still happens at the endpoint.

Stage 5: the governance layer (this is where platforms fail)

Publishing without governance just moves the chaos. Minimum viable governance for an agent registry:

1. Versioning. Semantic versions for agent behavior, not just code — a prompt change is a breaking change if output shape shifts. Keep old versions routable during migration.
2. Authentication and scoping. Service principals for calling agents; scoped credentials for the tools they call. Short-lived tokens over long-lived keys.
3. Sandboxed tool access. The published agent inherits every tool permission it carries — review them as part of publishing, like a firewall rule.
4. Observability from day one. Every call traced (OpenTelemetry GenAI conventions), with token spend attributed to the consuming team.
5. Cost and rate governance. Per-consumer quotas and budget alerts; a popular agent with no quota is an outage waiting for a busy Monday.
6. Approval flow. Staging → review → registry entry, with rollback to the previous version. The same peer-review discipline you apply to libraries applies to prompts and tools.

The anti-patterns

• Publishing the notebook. If your “service” is a Colab export, you’ve published a demo. Extract the agent into a package first.
• Card drift. Description says “summarizes tickets”, skills now include close_ticket. Update the card with every release or you’ve built a lie-based registry.
• Registry as ACL. “It’s not in the catalog” is not an authorization model — enforce at the endpoint.
• Skipping the consumer test. Before you announce, have another team integrate using only the card and docs. Where they stumble is your onboarding bug list.

The payoff

Do these five stages and the shape of an enterprise agent platform appears: versioned agent packages, transport-shaped hosting (usually A2A), a card that documents them, a catalog that indexes them, and a governance layer that keeps the whole thing accountable. That’s the difference between an org with a hundred agent demos and an org with an agent platform.