A change negotiation, not a conversation
CloudBasis isn't a chat system for agents. It's a commitment-based coordination system: what matters isn't the transient exchange, it's the recorded commitments and the evidence attached to them. Here's how a request crosses a boundary, what the owning side can do with it, and the states it moves through before anything merges.
Peer coordination, not manager-led decomposition
- 01 a consumer steward finds it can't complete the change locally
- 02 it raises a capability request against the provider steward
- 03 the provider evaluates it against its own invariants, policy and consumers
- 04 it accepts, rejects, asks for clarification — or proposes something safer
- 05 on agreement, each steward commits to its own side of the change
- 06 sdk, docs, event-consumer and integration stewards join if affected
- 07 CloudBasis validates the coordinated branch set
- 08 humans approve or arbitrate, and a merge plan is produced
Service B owns Service B. Service A may request an outcome; it never controls the shape of someone else's boundary.
A small set of software-specific actions, and none of the underlying ideas are new: speech acts from KQML and FIPA-ACL, task allocation from the Contract Net protocol, obligation from Winograd and Flores's Conversations for Action, and evidence from consumer-driven contract testing. Not message types. State transitions that create obligations.
object to proposal is architectural protection: it lets a steward say that a requested design violates the boundary, breaks compatibility, or belongs in another context.
A negotiation isn't done when an agent writes code. It's done when the commitments are satisfied and verified. Every state in between is explicit, so at any point you can say where a change is and who it's waiting on.
It isn't a straight line. counter-proposed sends the negotiation back to the requester carrying a different shape, and rejected, cancelled and escalated all end it before anything merges. Only satisfied means the commitments were kept.
Valuable long before full autonomy
The model gets stronger, not weaker, when a steward is human. AI can prepare the structured request, the impact analysis, the proposed contract and the draft PR. The human still accepts, rejects, counter-proposes or escalates.
Senior engineers lose a surprising amount of the week to this list. CloudBasis turns each answer into a reusable coordination artifact, and over time into the institutional memory of service ownership.
- who owns this api?
- can i add this field?
- will this break existing consumers?
- does this belong in this service?
- what migration path is safe?
- which repos need to change together?
- what should merge first?
- who needs to approve this?
- why was this design rejected last time?
It has to beat the two obvious alternatives
The harness will be a small but realistic polyrepo product (frontend, backend service, SDK, event consumer, integration tests) and tasks that force negotiation at the dependency edge.
One large generalist agent with access to every repository.
One manager agent decomposing work and delegating to repo workers.
Peer service stewards negotiating through typed commitments.
Human intervention count for cross-repo coordination.
And the question that has to separate us from a coding agent: did the system identify and preserve the correct ownership boundary?
Verify the whole branch set before production moves
A coordinated change set can be applied inside a forked, production-like environment: tests, agents and scenarios run against the combined change, and the resulting state diff becomes verification evidence on the negotiation.
CloudBasis negotiates the commitment. Forkable Reality proves what happens when it is kept.
Not mandatory. A higher-assurance verification layer for the changes that warrant it.
Coordination on top of the agent engineering stack
CloudBasis adds stewardship, negotiation and commitment state to existing AltairaLabs agent infrastructure. Define a steward, prove it behaves, run it, operate it.