Idea

Role contracts, with vendors as data

Work is assigned to a role with a contract; which model fills the seat is configuration, and reviewers can be a different vendor from builders on purpose

Platform principleThree systemsContracts · adapters · seat data
One seat, one contract, any occupant
Role contract · reviewer
receivesthe work and its evidence returnsa typed verdict may touchits tool classes, nothing else may spendits budget

Every model vendor would like to be the system. I treat them as workers. A job in my platform is addressed to a role with a contract: what it receives, what it must return, what it may touch, how much it may spend. Which model fills that seat, at what reasoning effort, under which account, is per-seat data. The same role can be filled by a frontier model through its subscription command-line tool, by an API seat, by a local open-source model on my own GPUs, or by a swarm job, and the contract does not change.

The shape

A role contract names inputs, outputs, tool classes and budget. A runtime adapter drives whichever vendor sits behind it through that vendor's native channel. A terms-of-service firewall decides at registration and at route time which vendor may sit behind which role, because subscription sessions are used as their vendor permits.

Who sits where Builders · one model family
Quality and adversarial reviewers · another
Blind spots, on one scale Builders' family
Reviewers' family

What one family misses, the other is placed to catch.

Where it appears

In AgentOS, vendors' interactive command-line tools run as durable governed seats behind one supervisor; and cross-vendor review is a design rule: Directing AI coding agents at program scale and Separation of duties for AI work.

In Agent Swarm, agents never hold a model address or key because the runtime proxies every call.

In Helix, one durable brain serves voice and chat surfaces alike: A self-hosted colleague in a Teams call.

AgentOS · one role, any occupant
reviewer
seat data picks which one sits
Agent Swarm · the endpoint pool
local GPU nodes
registered bridges
fallback
Helix · several vendors at one tableone adapter per vendor, one chair
Illustrative.

What it buys and what it costs

It buys independence: the organisation survives the model. It buys review diversity as policy rather than luck. It buys the use of subscriptions already paid for alongside API access and local models in one governed workflow.

It costs lowest-common-denominator interfaces and per-vendor quirks, each command-line composer needing its own number of keystrokes after a paste, for example, and it costs attention to vendor terms. I pay both.

The judgment in it

The contract is the product and the vendor is a supplier.

Designing it that way from the first job meant that when a better model arrived, or a cheaper one, or a local one good enough for a task, the change was a line of configuration.