CIO Deep Dive: Capability Packs and Agent-to-Agent

From projects to a platform

The first three agent projects in a company are built the same way: a team, a use case, an assistant, a few connectors, some prompts in a shared document. They work, and none of them share anything. The fourth team starts from zero, wires the same CRM a fourth time, and writes its own version of the "how we answer a customer" prompt.

A platform is what you have when the fourth team starts from the third team's work. That requires three things the project model does not have: a unit of reuse, a boundary between teams, and someone who owns the shared parts.

The unit of reuse: a Pack

A Pack is everything a person needs to do one job with an assistant, packaged so it can be handed to a group:

• Tools. The MCP servers, or the subset of their tools, the job requires. An accounts-payable Pack has the ERP's supplier and invoice tools; it does not have the HR system.
• Skills. The written playbooks: how this company matches an invoice, what "three-way match" means here, which exceptions go to whom. Skills are how a team's way of working travels to everyone's agent.
• Policy. What each tool may do for people in this Pack. Reads open, writes held for approval, bulk operations denied, and the named approver group.
• Model routing and redaction. Which models this Pack may use, in which region, and what is masked before a call leaves.

A Pack is assigned to a group in the identity provider. Everyone in the group gets it through their one governed connector, in whichever assistant they use; a new joiner has it on day one and a leaver loses it on their last. That assignment is the entire rollout.

The boundary: a Space

A Space is where a team's Packs, servers and approvals live. It is the boundary that lets Finance and Engineering share the same platform without seeing each other's tools, and it is where a team lead can see what their people are doing without an admin in the loop. Spaces are also where the platform team publishes shared servers, so that the CRM connected once is available to every Space entitled to it rather than connected again per team.

Who owns what

The platform team is small in this model: two or three people who own servers, policy templates and the reports. The work of deciding what agents do stays with the teams whose work it is.

Versioning and lifecycle

Packs change. A Skill gets a better exception rule; a server exposes a new tool; a policy tightens after an audit. Treat a Pack like a released artefact:

• Changes are reviewed. A change to a policy or a Skill is proposed, looked at by the Pack owner, and published, with the diff in the record. The audit trail should show not just what an agent did but what it was allowed to do at the time.
• Versions are pinned per group. Roll a new Pack version to one team before everyone. If first-attempt success drops, roll back.
• Deprecation is explicit. When a system is retired, its server is removed from the Packs that used it, and the people in those groups lose the tool the same day. No orphaned credentials.

Worked example: the Sales Pack

A regional sales team wants their assistant to prepare call briefs and draft renewals. The platform team already has CRM, billing and support servers published. The sales lead composes a Pack:

1. Tools: CRM account and opportunity reads; billing invoice reads; support ticket reads; CRM note write.
2. Skills: "How we run a renewal call" and "Discount bands and who approves beyond them", written by the sales lead in an afternoon.
3. Policy: reads open; the note write allowed; any tool that changes a price or a contract is not in the Pack at all.
4. Assignment: the identity-provider group "Sales-EMEA".

Forty people have it the next morning, in Copilot for most of them and Claude for the two who prefer it. When the North America team asks for the same thing a month later, they inherit the Pack, swap the discount Skill for their own, and are live the same day. That is the difference between a fourth project and a platform.

Where agent-to-agent fits

Agent-to-agent protocols such as A2A let an agent hand a task to another agent, possibly from another vendor, and get a result back. They sit above the layer described here: whichever agent ends up touching a system of record does so through a tool call, over MCP, and that is where entitlement, policy and approval apply. Palma governs that point. It does not govern the agent-to-agent conversation itself today.

In practice that means you do not need A2A to get value from Packs, and when you do adopt multi-agent workflows, the receiving agent should act with a person's connector, in a Pack, under the same policy. Give an orchestrating agent a service account with everything and you have rebuilt the shared API key the whole platform exists to remove. We wrote up the A2A picture separately in A2A and MCP: what the handover means.

Starting

Pick the team that has already built the most, make their work the first Pack, and publish the servers they wired as shared. Their second version is the platform's first. If you want help choosing, book thirty minutes and bring the list of agent projects that exist today; there are usually more than IT knows about.