A coworker can arrive as an endpoint, but not as a file

[jerelvelarde]

#299 was right to close and I am not reopening it. The scope argument holds: a catalogue that fetches
from pinned repositories presumes a population of deployments trading with each other, and a starting
point somebody clones once does not have one.

This is the narrower piece, and it is a different kind of thing.

The gap

The first hurdle after setup is "what now?" — see #397 for the half of that answer which is
just better examples in the box. This is the other half: somebody hands you a coworker.

The README already offers ingress for a coworker's runtime: "any AG-UI endpoint is a Bot, on a
framework or hand-written", validated with the same target checks as browser navigation. What a
deployment cannot do is take in a coworker's configuration. Somebody sends you a file describing a
coworker — its prose, its skills, what it wants to reach — and there is nothing to do with it but
read the YAML yourself and retype it into the dialog.

Editing examples/ and redeploying covers that for a repository you own. It does not cover a
deployment that is already running and that you would rather not restart, and it does not cover
somebody who is not the person with filesystem access.

Why this is not the catalogue

Distribution leaves the repository entirely. No pinned sources, no OPENBOT_TEMPLATE_SOURCES, no
server-side fetch, no allowlist, no URL to configure — and no code here that knows any list exists.
awesome-openbot-agents is a list a person
reads in a browser; getting a file out of it is a copy button.

That matters beyond scope. The product fetches nothing today and the posture is "runs on your
machine". A fetcher aimed at a URL somebody typed is the same class of problem checkAgentEndpoint
exists for, and adding one to justify a convenience is a bad trade. So: no fetch. You already have
the file.

What it costs

Against #299's 123 files and two migrations: no catalogue, no pinned sources, no gallery, no
categories, no shipped catalogue for a clone to inherit, and — the part I want to be held to — no
migration and no new table. Installing writes a coworker, its skills, and the one grant that pairs
them, into tables that already exist. On the order of fifteen files.

The safety argument, which you said was the reusable part

It is reusable precisely here, because the file arrives from outside. The format refuses what must
never travel — no endpoint, no credential, no grant, no component source, no policy rule — by not
having those fields, so a file carrying one fails to parse rather than being quietly stripped. The
consent screen renders every word the file would give a model, verbatim, before anything runs.

And it must not go through the tenant package loader. expandEnvironment runs over agents.yaml and
skills.yaml at load (tenant-package.ts:535,556), so a role description containing ${…} would be
interpolated out of the server's own environment. That is the concrete reason the package cannot be
the mechanism for a file you did not write — and the same reason a clone should be careful what it
points examples/ at.

Not #322

That asks for sharing configurations between deployments, and its acceptance criteria include
carrying grants across on import. This deliberately does not: what a coworker asks for arrives as an
ask and stays unanswered until somebody with the authority decides it. A file that can carry a grant
is a file that can grant.

Two questions, rather than a diff

1. Is ingress the piece that belongs, or is even one import screen more than a template should carry
   once What now? The example package is three coworkers and a blank page #397 has made the in-box examples good?
2. If it belongs — is "grant nothing, and show what was asked" enough without a table to record the
   asks in? Dropping that record is what gets this to zero migrations. The cost is that the asks are
   on screen once and not afterwards.