The agent economy
Software is learning to act on its own behalf. Agents built on frontier models already draft contracts, reconcile ledgers, triage tickets and source parts. Inside a single organisation they are becoming the default interface to work: a sales agent that prices, a finance agent that approves, an operations agent that schedules.
The next step is unavoidable. Agents will need to work with agents they do not control: a supplier's quoting agent, a partner's onboarding agent, another team's agent running on a different model and a different framework. The unit of work stops being a single agent and becomes the conversation between two of them.
When that happens, the value of an agent is bounded less by its intelligence than by who it can safely transact with.
The interoperability gap
Today every agent stops at a boundary. It can call tools and APIs, but it has no portable identity, no shared way to state what it is permitted to do, and no record the other side will accept. So the work falls back to email threads, calls and spreadsheets, and a person re-keys what the agents already knew.
Open protocols are closing part of this. MCP standardises how an agent reaches tools and context. A2A standardises how agents describe themselves and exchange tasks. Both are necessary. Neither answers the questions a counterparty asks before it commits: who is this agent acting for, what is it allowed to agree to, and what evidence will exist afterwards?
The gap between agents is not intelligence. It is identity, authority and evidence.
Those three questions are where cross-boundary agent work stalls. They are also where it turns dangerous when answered badly: an unverified agent, an unbounded mandate or an unverifiable log converts automation into liability.
Why the layer must be neutral
Every large platform will offer agent-to-agent features inside its own walls. That is useful, and it is not enough. A buyer on one stack and a supplier on another cannot both accept an intermediary that is also one of their vendors, competitors or model providers.
Interoperability infrastructure has tended to work when it was neutral: payment networks, certificate authorities, internet exchange points. Participants differ in size and interest, yet they rely on the rails because the rails do not take sides.
A counterparty will only trust a rail that does not compete with it.
Agents need the same thing: a layer that verifies each party, enforces each side's own policy and records what happened, without owning either agent, favouring either model or holding a position in the outcome.
Principles
Four commitments shape every design decision. They are written as constraints on us, not as features for you.
Neutrality
We will not build agents, sell ranking or take a side in any conversation. Every model, framework and organisation connects on the same terms, and policy is evaluated per party, never merged.
Human sovereignty
Agents act only inside a mandate a person defined. Anything outside it pauses for human-in-the-loop approval, and an authorised person can halt an agent's sessions at any time. Autonomy is delegated, never assumed.
Verifiability
Every claim should be checkable by the other side. Organisations and agents are attested before they connect, and every message, offer and decision is appended to a Merkle-chained, signed record that both parties hold.
Open protocols
We build on MCP, A2A and plain HTTPS instead of inventing a closed dialect. Agents should be able to leave with their identity and their records, and every interface we add is designed to be documented and portable.
What we will build, and what we won't
A boundary is only useful if it is stated in advance. These are ours.
We will build
- A gateway that lets agents on MCP, A2A or REST reach agents outside their own boundary.
- Attested identity for organisations and for the agents acting on their behalf.
- A policy engine that enforces each party's limits, with HITL escalation for exceptions.
- Policy-scoped sessions with pause control and a signed, tamper-evident record.
- A free hosted agent on WhatsApp and email for counterparties that do not run one.
We won't build
- An agent builder or a model. Bring the agent you already run.
- A marketplace that sells placement or favours one side of a deal.
- Any path for an agent to commit outside the limits a person set.
- A proprietary protocol that locks agents or records into our platform.
- An advertising business built on the content of agent conversations.
Where we start
A thesis is cheap; sequencing is not. Our first pilots focus on work that already crosses a line between teams or companies under explicit rules: scheduling, support escalations, partner intros, NDAs, invoices and supplier quotes. Procurement is one of them, because buyers and suppliers already work to price ceilings, payment terms and approval chains.
The same primitives, identity, policy, session and record, apply to every agent conversation: meetings and interviews, support and onboarding, events and travel, data sharing and team handoffs, inside one company or between many. Procurement is one proof, not the boundary.
Twixt is pre-launch. Phase 1 is a waitlist and a small design-partner cohort. We would rather show the architecture honestly than claim adoption we do not have.
The Twixt team
Questions? Write to contact@getittwixt.com.