Some answers aren't in the code. CloudBasis is where the agent asks for them.
Your agent can read every line and still not know whether a change is allowed, who else depends on it, or why the same design was rejected last year. That's not a context problem. It's a decision another team owns, and no amount of searching will find it.
Every one of these is the right call on the day
Agents made writing code cheap. They didn't make getting agreement cheap. When a change needs something another team owns, your agent can read that team's code. It can't get their sign-off. So it does the sensible thing available to it, and the sensible thing available to it isn't the right thing for the system.
Duplication, disconnected capabilities and fudge compound into a knot that even the most powerful model can't untangle.
This is the part that doesn't fix itself. Each workaround is cheap on the day and permanent afterwards, and the next agent inherits all of them as the codebase it now has to reason about. A better model doesn't undo any of it. It just works faster in the same knot.
What CloudBasis is
Product definitionA service-ownership coordination plane for human and AI software stewards.
CloudBasis doesn't need to be the best coder. It needs to be the best system for making AI-generated changes safe across service boundaries.
- another coding assistant
- a manager agent that decomposes tasks
- a chat system for agents
- a recipe-driven mass-refactoring tool
- a git host or a replacement ci/cd platform
A steward is defined by the boundary it owns, not by what runs behind it: a commercial coding agent, a local model, an Omnia-hosted agent, or a human being. CloudBasis coordinates the commitments. It doesn't prescribe how they're met.
Each agent sees its own code, and everyone else's contracts
That constraint is the whole design. A steward works inside one bounded context, small enough to hold and coherent enough to reason about. Everything beyond it shows up as a contract and the steward who owns it. Never another service's internals. So when a change needs something it can't build locally, it's got no option but to ask.
It doesn't fit. Point an agent at every repository and something has to summarise and filter before it can use any of it. That filter is where the fidelity goes, and you don't get to see what it dropped.
What it can read, it'll use. An agent that can see another service's internals will build against them, because they're right there and they work. That's a dependency nobody agreed to and nobody's tracking. It breaks the day those internals change.
Reading everything and filing tickets for the parts you can't touch looks like the sensible middle ground. It keeps both problems and adds a queue.
Every negotiation resolves to a record: who asked, what was refused and why, what each side committed to, and what was verified before anything merged. That record is the product. It's what makes the next change cheaper instead of more expensive.
It's also where "why was this design rejected last time" gets answered. That decision is usually written down somewhere. Almost never where the next change is being made.
change negotiation #482 initiating context web-app target context payments-api capability cancel after authorisation reason checkout flow · consumer evidence affected contracts openapi · paymentcancelled constraints backwards compatible consumer expectation contract test attached provider response counter-proposal objections breaks two known consumers commitments provider · consumer · sdk change set 5 branches verification contract · integration · policy human approval required outcome merge plan issued
The full protocol is on the protocol page: the speech acts, the domain objects, and the lifecycle a negotiation moves through.
AI-assisted API and schema evolution across polyrepo systems
Not arbitrary multi-agent coding. One wedge that's narrow, painful and testable: the place where ownership boundaries bite hardest and the evidence is unambiguous.
a frontend change needs a backend capability
cloudbasis detects the change crosses a boundary
the frontend steward raises a capability request
the backend steward rejects the initial api shape
and proposes a safer contract
cloudbasis records the decision
backend, sdk and frontend changes are produced
as one coordinated pr set
contract and integration tests run on the set
cloudbasis presents a merge plan
a human approves the negotiated change Private preview
We're looking for design partners running polyrepo products where API and schema evolution already costs senior engineering time, and who want their ownership boundaries preserved, not flattened.
- polyrepo products with real boundaries
- openapi · protobuf · event schemas
- shared sdks and generated clients
- consumer-driven contract testing
- internal developer platforms
- teams already running coding agents