The Package Registry — Share, Discover, and Deploy Agentic-Nets Like npm for Agentic Processes

Posted on

The Package Registry — Share, Discover, and Deploy Agentic-Nets Like npm for Agentic Processes

You’ve spent hours building the perfect Gmail triage pipeline — an Agentic-Net that fetches emails, categorizes them with an LLM, routes urgent ones to Slack, and archives the rest. It works beautifully. Now your colleague wants the same thing for their team. What do you do? Copy-paste JSON? Export a tree dump? Walk them through recreating it from scratch? AgenticOS now has a better answer: package it, publish it, and let anyone install it with a single command.

The Problem: Brilliant Nets That Live and Die Alone

Agentic-Nets are powerful. A well-designed net encodes not just an agentic process, but an entire operational strategy — the places that hold state, the transitions that transform data, the inscriptions that define behavior, and the tokens that carry domain knowledge. But until now, every net was an island.

Building a net required starting from scratch: define places, wire transitions, write inscriptions, seed tokens. Even if someone had already solved the exact same problem, there was no way to benefit from their work. No registry. No versioning. No import mechanism. Every team was building in isolation.

This is the same problem that software development had before package managers. Imagine writing JavaScript without npm, or Python without pip. Every project would reinvent HTTP clients, date formatters, and authentication flows. Package managers turned isolated code into a shared ecosystem. AgenticOS needed the same thing for agentic processes.

The Idea: npm for Agentic-Nets

The Package Registry turns finished Agentic-Nets into versioned, self-contained artifacts that anyone can discover, inspect, and deploy into their own AgenticOS environment. Think of it as npm for agentic processes — but instead of JavaScript modules, you’re sharing entire operational systems complete with their topology, behavior, and optionally their seed data.

The core insight is that an Agentic-Net is defined by three layers, and different sharing scenarios need different combinations:

Three Package ScopesChoose what to share — topology only, executable config, or the full artifactdesigntimeShare the blueprintPNML (topology)inscriptionstokensruntimeShare the executablePNML (topology)inscriptionstokenscompleteShare everythingPNML (topology)inscriptionstokensTeaching / templatesReady-to-run pipelinesFull deployable artifacts with seed data
  • designtime — PNML only. Share the net topology so others can see the architecture and configure their own inscriptions. Perfect for teaching, templates, and reference architectures.
  • runtime — PNML + inscriptions. Share an executable net that’s ready to fire. The recipient gets the full behavior definition — ArcQL queries, action configs, emit rules — without seed data.
  • complete — PNML + inscriptions + tokens. Share absolutely everything: the topology, the behavior, and the initial data. Import it and it’s immediately operational.

How It Works: Create, Publish, Discover, Deploy

The lifecycle of a package follows four clear steps. You build a net in your workspace. You package it — choosing what to include. You publish it to the shared registry. Others discover it and import it into their own environment. Every step is available through the GUI, CLI, and agent tools.

Package LifecycleFrom workspace net to shared, deployable artifactCreateExport net + inscriptions+ tokens by scopePublishCopy from user modelto shared registryDiscoverSearch by name, tagsBrowse the catalogDeployImport into sessionHost rewriting includedYour Model/root/packages/Shared Registrydefault modelREST APIGET /api/packagesTarget Sessionnet + inscriptions + tokensGUI / CLI / AgentGUI / CLI / AgentGUI / CLI / AgentGUI / CLI / Agent

Step 1: Create a Package

Packaging starts with a workspace net. The system exports the PNML topology, then — depending on the scope you choose — collects inscriptions from each transition and tokens from each place. It scans inscriptions for Docker image dependencies and assembles everything into a single self-contained JSON document.

# CLI: Package a net with full scope
agenticos package create my-net-id \
  --name gmail-inbox-manager \
  --version 1.0.0 \
  --scope complete \
  --description "Automated Gmail inbox triage with LLM categorization" \
  --tags gmail,email,triage

Step 2: Publish to the Registry

Creating a package stores it in your private model space. Publishing copies it to the shared default model where other users can discover it. This two-step process lets you iterate locally before sharing with the world.

# Publish to the shared registry
agenticos package publish gmail-inbox-manager --version 1.0.0

Step 3: Discover Packages

The registry is searchable by name, description, and tags. Whether you’re looking for email automation, data pipelines, or CI/CD pipelines, you can find what others have built and inspect it before importing.

# Search by keyword
agenticos package search gmail

# Browse all published packages
agenticos package list

# Inspect a specific package
agenticos package info gmail-inbox-manager

Step 4: Deploy Into Your Session

Installing a package creates the full net in your session — places, transitions, arcs — and stores inscriptions and tokens. The system automatically rewrites host references so everything points to your local environment. One command gives you a fully operational net.

# Install the latest version
agenticos package install gmail-inbox-manager

# Install a specific version
agenticos package install gmail-inbox-manager --version 1.0.0

# Output:
# ✓ Installed gmail-inbox-manager@1.0.0: 6 places, 4 transitions, 4 inscriptions, 8 tokens

The Package Format: Self-Contained and Portable

A package is a single JSON document that contains everything needed to reconstruct a net in any AgenticOS environment. It’s human-readable, version-controlled, and complete — no external references, no missing pieces.

{
  "format": "agentic-net-package",
  "formatVersion": "1.0.0",
  "scope": "complete",
  "manifest": {
    "name": "gmail-inbox-manager",
    "version": "1.0.0",
    "description": "Automated Gmail inbox triage with LLM categorization",
    "author": "alexej",
    "tags": ["gmail", "email", "triage"],
    "createdAt": "2026-02-21T14:00:00Z",
    "agenticosVersion": "1.0.0"
  },
  "net": { },
  "inscriptions": {
    "t-fetch-emails": { "id": "t-fetch-emails", "kind": "http", "..." : "..." },
    "t-categorize":   { "id": "t-categorize", "kind": "llm", "..." : "..." }
  },
  "tokens": {
    "p-config":       [{ "name": "gmail-settings", "data": { "pollInterval": 300 } }],
    "p-instructions": [{ "name": "triage-prompt", "data": { "instruction": "Categorize..." } }]
  },
  "dependencies": {
    "dockerImages": [
      { "repository": "agenticos-tools/gmail-connector", "tag": "latest" }
    ]
  }
}

The net field contains the full PNML export — places with coordinates, transitions with labels, arcs with routing. The inscriptions map holds the behavioral definitions for each transition. The tokens map holds seed data for each place. And the dependencies section lists any Docker images the net requires, discovered automatically by scanning inscriptions.

Host Rewriting: The Hidden Challenge of Portability

Here’s a problem that’s easy to overlook: inscriptions contain host references. When you create a net, presets and postsets point to specific model IDs and host addresses — user-alexej@localhost:8080. If someone imports that package into their own environment, those references are wrong. They point to a model that doesn’t exist in the target system.

The import process solves this with automatic host rewriting. Every inscription is walked and every host reference — in presets, postsets, and action configs — is rewritten to point to the target model and host. The original package is never modified; rewriting happens at import time, producing a clean local copy.

// Before import (original inscription)
"presets": {
  "input": {
    "host": "user-alexej@localhost:8080",
    "placeId": "p-emails"
  }
}

// After import (rewritten for target environment)
"presets": {
  "input": {
    "host": "user-bob@localhost:8080",
    "placeId": "p-emails"
  }
}

This is what makes packages truly portable. The topology and behavior travel with the package. The addressing adapts to wherever it lands.

Three Interfaces, One Registry

The Package Registry is accessible from every AgenticOS interface — the GUI, the CLI, and the AI agents. Each serves a different agentic process, but they all use the same underlying API.

GUI: Browse and Publish Visually

The new Packages tab in the sidebar provides a visual registry browser. Search published packages, filter by tags, expand cards to see readmes and version history, and import with a single click. The publish form pre-fills from your workspace net — choose the scope, add tags, and share with the community.

CLI: Scriptable Package Management

Six subcommands give you full control from the terminal. agenticos package create packages a net. agenticos package publish shares it. agenticos package search finds packages. agenticos package install deploys them. Every command supports JSON output mode (--output json) for scripting and CI/CD integration.

Agent Tools: AI-Driven Package Operations

Three new agent tools — PACKAGE_SEARCH, PACKAGE_PUBLISH, and PACKAGE_INSTALL — let AI agents interact with the registry as part of their autonomous agentic processes. An agent building a new pipeline can search for existing packages, install relevant ones, and build on top of proven foundations instead of starting from scratch.

This is where the compounding effect kicks in. As the registry grows, agents become more capable — not because they’re smarter, but because they have more building blocks to work with. An agent that can PACKAGE_SEARCH for “email triage” and PACKAGE_INSTALL the result is dramatically more productive than one that must construct every transition from primitives.

What This Enables: From Isolation to Ecosystem

A package registry isn’t just a convenience feature. It changes the economics of building with AgenticOS:

  • Reuse over rebuild. A well-tested Gmail triage net becomes a building block, not a one-off project. Install it, customize the prompts, and you’re running in minutes instead of hours.
  • Template libraries. Share designtime packages as architectural templates — “this is how you structure a fan-out/fan-in pipeline” — without prescribing specific configurations.
  • Versioned deployment. Pin packages to specific versions. Roll back if a new version introduces problems. Track what changed between 1.0.0 and 1.1.0.
  • Team collaboration. One team member builds and publishes a net. Others install and extend it. Domain expertise gets captured in the package, not lost in someone’s head.
  • AI acceleration. Agents that can search and install packages bootstrap complex agentic processes faster. The registry becomes collective memory for the entire system.

Try It Yourself

The Package Registry is available now. If you have a workspace net worth sharing, package it:

# Package your net
agenticos package create my-net \
  --name my-awesome-pipeline \
  --version 1.0.0 \
  --scope complete \
  --tags automation,pipeline

# Publish to the registry
agenticos package publish my-awesome-pipeline --version 1.0.0

# Someone else installs it
agenticos package install my-awesome-pipeline

Or use the GUI: open the Packages tab in the sidebar, fill in the publish form, and click publish. Browse published packages in the same panel and import with one click.

The REST API is also available directly for integration:

# Search published packages (no auth required)
curl "http://localhost:8083/api/packages?search=gmail&limit=10"

# Get package details
curl "http://localhost:8083/api/packages/gmail-inbox-manager"

# Import into your session
curl -X POST "http://localhost:8083/api/packages/gmail-inbox-manager/versions/1.0.0/import" \
  -H "Content-Type: application/json" \
  -d '{"targetModelId": "user-bob", "targetSessionId": "my-session"}'

Where This Leads

This is Phase 1 — a local registry within a single AgenticOS instance. The architecture is designed to grow:

  • Git-backed distribution. Push packages to a GitHub repository. Install from any Git URL. Use PRs for package review. Free hosting with built-in access control.
  • AgenticOS-to-AgenticOS federation. Share packages directly between AgenticOS instances across networks. Remote registries with JWT authentication.
  • Package signing and trust. Verify package integrity and authorship. Build a web of trust for the ecosystem.
  • Dependency chains. Packages that depend on other packages. Install a high-level agentic process and its building blocks come along automatically.

The vision is clear: an ecosystem where the best operational patterns are shared, versioned, and deployable. Where every Agentic-Net you build stands on the shoulders of every net that came before it. Where the cost of solving a problem drops to near zero once someone has solved it once.

Agentic Processes shouldn’t live and die alone. Now they don’t have to.

This article — and the feature it describes — were built using AgenticOS’s own agentic agentic process tools. The Package Registry implementation spans the master service (Java/Spring WebFlux), the gateway, the CLI (TypeScript), and the Angular GUI.

Created February 21, 2026.

Leave a Reply

Your email address will not be published. Required fields are marked *