Skip to content

Shipping a knowledge pack with a QuickAgent

A QuickAgent can bring a knowledge pack of its own. Every run of it then has that reference material, with no one attaching anything: a review agent that always has the style guide, an assistant that always has the product's manual. This page is for the person who publishes the QuickAgent. Read it before you ship a pack, because what you ship becomes readable by everyone who can download the release.

What shipping does

A shipped pack is part of the release, not a pack kept in Agentry.

  • It is in the release's archive, under knowledge/<name>/, and the manifest names it in knowledge.ships. The Builder, the desktop app and the CLI write both for you.
  • It is not encrypted. Anyone who can download the release can read it: anyone at all for a public QuickAgent, and the people who can see it for a private one.
  • It is scanned with the version. The rule stages read every page and source, and AI Review reads the sources and then the wiki, in chunks. The findings are the release's findings and the gate decides on them like any other. A pack the scan could not read in full sends the version to review. The version's page says what was read under Knowledge this release ships, and the pack is signed with the rest of the release.
  • Every run reads it. The runner mounts it read-only at /knowledge/<name>, beside any pack the person attaches, and the run searches it with the same three knowledge tools. It works the same on a person's computer and In Agentry.
  • It is in the contract. The QuickAgent's page lists it with its size under the declared capabilities, as "knowledge: ships N", and a new version that ships another pack asks for consent again when someone updates.
  • It stays in that version. To change a pack, publish a new version.

The confirmation

Every place that ships a pack asks you to confirm it first, one pack at a time:

aws-docs (4.2 MB) becomes public. Anyone can download it with this release, and it stays in this version for good: retiring or deleting the QuickAgent later does not recall copies already downloaded. Check that it holds no private data: names, emails, customer records, internal hostnames, keys.

For a private QuickAgent the first sentence says everyone who can see the QuickAgent can read the pack. The Builder's Submit is always public, so it always asks the public wording.

The question is there because nothing can tell your pack's own text from a secret that landed in it. The scan reports what it finds, but it does not promise a pack is free of private data. Open the pack from its page in Agentry and read it before you tick the box. Names, emails, customer records, internal hostnames and keys are the usual ones. Once a version ships a pack, people can have copied it, and retiring the QuickAgent does not take those copies back.

The registry refuses a release that ships a pack without the confirmation, and keeps with the version who gave it and when.

Where you can ship from

  • The Builder. The Knowledge step lists your packs kept in Agentry whose scan has finished. Tick up to five, then tick the confirmation under each. Submit stays off until every one is ticked, and the confirmation page you reach from Submit asks each pack again. Save puts the packs in the package on your computer and publishes nothing.
  • Describe it to AI. Under the description, each pack you pick is either Read while drafting, the default, or Read and ship with the QuickAgent. Where Agentry does not offer shipping from a draft yet, the page says the Drafter only reads. Choosing to ship asks the confirmation for that pack, and the Drafter writes the instruction to use it at /knowledge/<name>. The draft ships only the packs you chose to ship, and Review shows them ticked, so Submit asks again. A pack of an organization is offered to its admins, and the draft is then made for that organization's namespace. A pack you tick later, in the Builder's review, ships too, with a note that the instruction may not mention it.
  • Edit and Edit with AI. Both keep the previous version's packs on the form (below). The Drafter's revision does not carry them: they stay ticked on the form, and publishing the version reads them and asks the confirmation.
  • The desktop app, 0.6.145 or later. Build has a Knowledge section with your packs, kept on your computer or in Agentry. Describe it offers Read or Read and ship for each pack, Edit keeps the previous version's packs, and Make public asks again. Each pack's confirmation is a dialog of its own.
  • The CLI, v0.6.155 or later. agentry knowledge ship PACK puts a pack in the package. agentry draft --ship PACK ships it from a draft. agentry publish asks about each pack and --yes answers for scripts (the command).

The MCP server does not ship packs. Ship from the terminal, the desktop app or the site.

Organization packs

An organization can keep shared packs (an organization's shared knowledge). One of them can ship with a QuickAgent under two conditions:

  • You are an admin of the organization. A member who is not an admin does not see the pack in the list, and the registry refuses the release if they send it.
  • The QuickAgent is in the organization's namespace. The Builder shows the organization's packs, under Shared with organization, while the namespace field names that organization.

The registry checks both again when the version arrives, and that the files shipped are the shared pack as Agentry keeps it. It writes org.knowledge_ship to the organization's audit log for each such pack: the pack, the QuickAgent, the version and who shipped it, and nothing of the pack's content.

An admin who exports an organization's pack and copies it into a package by hand ships it as their own files. The registry cannot tell the difference, and the audit log has no line for it. It is their organization's knowledge to ship, and the confirmation still applies.

Edit keeps and refreshes packs

Edit and Edit with AI keep the previous version's packs, ticked. Each is matched by name to a pack you keep now: your own, or the organization's for an admin editing a QuickAgent in its namespace.

  • Every ticked pack is read again when you submit. A pack you changed in Agentry since the last version ships with its new content. To drop a pack, untick it. To add one, tick it.
  • The confirmation is asked again, for every pack the new version ships.
  • A pack that cannot ship is left unticked and named. That means one you no longer keep, one whose scan has not finished, or an organization pack you are no longer an admin for. Nothing carries over silently.

The version you started from keeps what it shipped.

Make public asks again

A private QuickAgent that ships a pack in one of its versions asks again when you make it public, because public lets anyone download every version. The page names each pack and the versions that ship it, and Make public stays off until you tick each one. On the desktop, each pack gets a dialog.

The registry holds this too: through the API, making a QuickAgent public is refused with 409 shipped-knowledge-unacknowledged while a version other than a yanked or rejected one ships a pack, unless the request carries acknowledgeShippedKnowledge: true. Yanking those versions opens the way without the confirmation.

Limits

  • 5 packs in a release.
  • 10 MiB and 2,000 files in each pack, its manifest.json included. A pack's files do not count toward the release's own file and size limits.
  • 16 MiB compressed for an upload through the site, the desktop app or agentry publish. A larger release is published by pushing its tag.

A pack past these limits is refused before anything is sent, with the pack named.

A tag push ships without a confirmation

Pushing a tag to your QuickAgent's repository publishes a version with no client in between, so nothing asks. If the release ships a pack, the registry accepts it and records the version as published from a tag push, with no one's confirmation. The Publish button on your QuickAgents page sends a tag the same way. Releases past 16 MiB have to go this way.

The responsibility is the same as for any other path: before you push the tag, check that every pack under knowledge/ holds no private data. The scan helps and does not replace reading it.

Procedure pages are reference

A pack's wiki can hold pages that read as procedures: the steps of a release, a checklist for a review. The run reads every page in a pack as data. A page cannot change the task, grant the QuickAgent a tool, or override its instructions, whatever the page says about itself.

So write the instruction to use the page. Say when to look ("when the task is a release, find the release procedure in the pack, read it, and do its steps in order") and what to do when the pack is silent. The steps the QuickAgent can take are the ones its manifest allows. A procedure page that asks for a command or a host the manifest does not declare is not followed. Describe it to AI writes the instruction this way for a pack you ship.