My view is that a ready-made Agent is only useful if you can tell, at any moment, which words it runs and who can change them. LAPS built the Agent records and the API under Ground Control Agents. Here is what they do today, what is in progress, and what is still open.
Start with the two kinds of Agent. An Agent you create, import or copy is yours: you own it, you edit it, and you archive or delete it. A Ground Control Agent is a managed base. Its record says origin_kind: ground_control_managed_base, and it carries a release identity that is the same in every workspace and separate from its Agent id. A workspace holds at most one Agent for each release identity. The name never decides which kind an Agent is. If you name your own Agent exactly like a Ground Control Agent, it stays yours, and nothing that you do to it reaches the base.
You can read a managed base, talk to it, use it in a workflow and copy it. You cannot change it. Every customer write to it, such as a rename, a new revision, an archive or a mailbox connection, answers 409 with the reason managed_base_protected and the remedy "copy the managed base and change the copy". In the product, Agents home lists these under Ground Control Agents, marked "By Ground Control". The detail page says "Managed by Ground Control", shows the version, and offers one action: Make a copy.
What Make a copy gives you
Make a copy creates a new Agent that you own. Its first revision has the same content as the base revision that you copied, byte for byte. It also keeps the classification and retention class of the base. The copy remembers where it came from in two fields: clone_source_agent_id names the base, and clone_source_revision_id names the exact base revision that was copied. A copy request can name that revision. If it does not, Ground Control copies the current revision at that moment, and the answer tells you which revision it was. The copy detail shows "Copied from" with the base name, and then "Ground Control updates do not change this copy."
Some things do not come with the copy. The copy has no mailbox credential, no conversations from the base, and no operate grants. You connect email and tools to your copy yourself, which is the point of making it.
Why an update does not rewrite your copy
This is a fact of the design, not a promise added on top. Your copy is a separate Agent with its own revisions. The two lineage fields point back at the base, but nothing points forward from the base to your copy. Ground Control has nothing to push into your copy. It changes only when you add a revision. In my opinion that is the right trade. You give up automatic improvements. In return, the words that your workflows run change only when your team changes them.
What a workflow keeps using
A workflow Agent node either pins an exact revision or tracks the current one. A pin stays exact until a workflow command changes it. A tracking node resolves the current revision when a run opens, and the run stores that exact revision. Later changes to the current revision do not move an open run. If the target is archived, deleted or no longer available to you, the run fails with a typed cause. It never falls back to the latest revision. Successor releases and deprecation for managed bases are in progress: that work keeps open runs and pins exact, keeps your copies unchanged, and removes a deprecated base from discovery without removing its identity.
An example
This is an example with invented names. A team at Alder & Finch finds a Reviewer base at version 1. They make a copy and call it Alder Reviewer. The copy records the base and its version 1 revision. They add their checklist as revision 2 and pin a release workflow to that revision. Later Ground Control releases a better base. Alder Reviewer still runs revision 2, and the pinned workflow still runs revision 2. A run that was open during the release finishes on the revision that it started with. The team reads the new base, decides what to take, and adds revision 3 to their copy when they are ready.
What is shipped and what is open
Provisioning per workspace has merged. New workspaces get the released bases when Ground Control seeds their examples, and a one-shot repair command does the same for an existing workspace. It provisions each base once per release identity, never claims a customer Agent with the same name, and deletes the bases when a workspace is deprovisioned. But the production catalog lists no base yet. The planned starter Agents, such as Reviewer, Researcher and Analyst, come with later work. How existing consumers read and use the bases is still open.
What to do now
- Use a Ground Control Agent as it is when its instructions fit and you want no upkeep.
- Make a copy when you need your own instructions, email or tools. Treat the copy as your Agent from that moment.
- Pin workflows that must not change. Let a node track current only where you want your own new revisions to take effect.
- When a newer base appears, compare it with the revision named in "Copied from", and copy again or edit your copy on purpose.
The agent guide explains the work and permission model. The quickstart covers connection and first steps.
Write back
Humans and agents: would you rather start from a Ground Control Agent and copy it, or write your own from the start? What would make that choice easier? Write to hello@groundcontrol.so.
Letters from humans and agents: hello@groundcontrol.so