Coaching is a file now
One public repository used to be fine. With agent teams, the thing that says how your engineers work is an artifact for the first time, and I would not expect most teams to want it published alongside the product.
The argument
You used to coach engineers in review comments and design meetings. None of it could be published, because none of it was a thing you could publish.
Now it is a directory. So for the first time you have to decide whether it goes out with the product, and I would expect most teams to decide it does not.
One public repository used to be fine. The product was the code, and publishing the code published the product. Whatever else the team knew stayed where it had always been, which was nowhere you could point at.
What agent teams add that was never there before
An agent team is a set of definitions. Which agent owns what, how each one behaves, what it refuses, what it hands back and to whom. Written down, versioned, reviewed. That is not documentation about your engineering practice. It is your engineering practice, in the only form it has ever existed in outside somebody's head.
Think about what your engineers are actually doing now. They used to be coached, and now they are doing the coaching, through configuration. Same job, and a different medium: instead of telling a colleague what good looks like on this team, they are writing it down where an agent will act on it every time rather than once.
That coaching used to be unpublishable, and not because anybody was hiding it. It was not a thing. It lived in a review comment, in what a senior engineer said in a design meeting, in the standard everyone on the team knew and nobody had typed. There was no file, so there was no question about where the file went.
Now there is a file, and a file has to be somewhere. For the first time you have to decide whether how your team works ships alongside what your team built.
I would keep it private, and I think most teams will
Not because there is anything embarrassing in it. Because it is the accumulated judgment of your team about how work should be done, it is the thing that decides whether the output is any good, and it is now copyable in a way it never was when it lived in people. A user installing your product needs the product. They do not need the roster, the decisions behind it, or the half-finished argument about what an agent should refuse.
So: a private repository where the team and its definitions live, a public one that is what a user installs, and a publish step between them.
Publishing is a filter, not a branch
The step that makes it hold is that publishing writes a tree rather than a history. Each release lands as a single commit carrying the current published set, at the same paths the files occupy in private.
Which answers a problem people meet the hard way, by never creating it. A repository keeps every blob it has ever held, so deleting a file at the head does not remove the version you deleted. Publishing a tree means the public repository never held it. Not "no longer holds". Never held. That also rules out the arrangement that looks safest and is not, a private branch and a public branch in one repository: branches share a single object store, so a blob committed on either is fetchable from the whole thing.
The corollary is that nobody works in the public repository. Its history is a publish log, and a hand edit there is a change no gate reviewed that the next publish will silently revert.