Teams is what you have; Marketplace is what you add
Two verbs, two places: Teams and Agents show the capability you already have, Marketplace is where you add more. And a Review item is now a recommendation — because a proposal is a document a client reads, not a decision on your queue.

Two renamings shipped today. Neither changes a row in the database. Both change what a person has to hold in their head to find something, which is the only thing navigation is for.
Two verbs, two places
Marketplace had become one long page: the plugins you could switch on, then the agents you had not hired, then a "See also" row linking sideways to Teams and Skills and Evals — three lists answering two different questions, with cross-links apologising for the crowding.
The split is one sentence, and it is the owner's:
Teams/Agents = where you go to see your agents and capabilities. Marketplace = where you go to add capability (hire agents, enable plugins).
So Marketplace now owns a tab strip, and both tabs are the same verb: add.

Plugins is what this workspace can turn on — a bundle of agents, skills, object types, pages
and measures that composes under your workspace in one switch, written as one line in
workspace.yaml and applied. Agents for hire is the roles you have not hired yet: open a
profile and see what an agent does before you add it to the team.

Every agent in that catalogue works from uploads on day one; connecting a system later deepens it rather than switching it on. That is the point of a hiring surface rather than an integration checklist — you are choosing a role, not a connector.
And Teams & agents keeps the other verb. It is where you see who works for you: each team, its lead, its roster, the one person accountable for it. Nothing to buy, nothing to enable.

The "See also" row is gone from all four pages that mounted it. What replaced it is a single sentence at the top of the Agents page — hire another from the Marketplace — because a link that says where to go is worth more than a row of links that says everything is related to everything.
A Review item is a recommendation
The second renaming is one word, and it is a word we had overloaded.
A proposal is a GTM artifact. It is the client document the Proposals plugin writes: sheets,
a price, a scope, a thing a buyer reads and takes to their finance team. It lives at
/gtm/proposals, the Proposal Writer writes it, and it has a whole
render-verify-and-red-team loop of its
own.
What you decide in Review is not that. It is an action an agent looked at the work and recommended taking — update this deal's stage, send this follow-up, enrol this contact — where approving it is what executes it. That is a recommendation, and calling it a proposal made two unrelated nouns share a name in the same product.
So the queue says what it is. A row reads CRM update › recommended by pipeline-analyst. The focus screen is headed Recommendations, the fact label is Recommended by, and the empty state reads New agent recommendations land on the review queue for your decision. Twenty-one user-visible strings moved.

There was a knock-on, and it is the more interesting half. A kind already called "Recommendation" existed — the one for changes the team proposes to itself: roles, models, budget. That description only ever covered a third of what it actually is. The same kind is raised when the data-room collector is not confident enough to file something on its own, and when feedback is turned into work. What all of those have in common is a short list the team narrowed down with one option marked. So it is now called a Choice, and its blurb says that: a short list the team narrowed down, with the one it recommends marked — take it or pick another.
Ten kinds now, each with a chip and a count: Recommendation, Ruling, Approval, Choice, Gate, Run, Input, Credential, Merge, Suggested rule. They are written up on the new Review page.
Nothing stored moved
This is wording. The stored kind is still proposal. propose_action is still propose_action,
action_run rows are untouched, every ?kind=proposal URL still resolves, and the GTM Proposals
app keeps its name. If you have built against the API, nothing about this release moves under
you.
Which is the right shape for a renaming. The label is what a person reads; the identifier is what a system depends on. Changing the first should never cost you the second.