Composal/Vision
The third loop: Continual Agent Verification
CI checks code. CD checks delivery. CAV asks whether users can still succeed as the product changes.
Imagine a release that passes every test and deploys cleanly. A customer opens an invitation they received yesterday, signs in, and lands in the wrong workspace. The application is running. The customer still cannot join their team.
That gap is the business Composal is in. We want teams to know whether the product works for the person trying to use it, and to keep answering that question as the product changes.
I think about that responsibility in three parts.
- CI
- Code correctness
- CD
- Deployment correctness
- CAV
- Product correctness
From a green build to a working product
Continuous Integration gives us confidence that changes work together. Continuous Delivery keeps them ready for release; continuous deployment takes successful changes into production automatically. These practices can include extensive tests of user behavior. Their boundaries overlap, as do the checks inside them. AWS’s CI/CD overview describes that relationship.
The third responsibility is product correctness: can the intended user accomplish the intended task?
We call the process Continual Agent Verification, or CAV. Agents use the running product, pursue user goals, and bring back evidence of what works and what breaks. The shorthand is useful: CI for code correctness, CD for deployment correctness, CAV for product correctness. Each builds confidence in a different part of the journey; none is a guarantee that everything works.
A test might confirm that an invitation was created and an email was sent. The user’s goal is to invite a colleague who can reach the right project with the right permissions. That journey crosses accounts, sessions, and releases.
An agent can follow the invitation, encounter an existing account, inspect the destination, and check what the invited user can access. Starting from the goal gives it room to investigate a failure the original script did not anticipate.
CAV belongs alongside CI and CD. It can exercise a preview before a merge, revisit important journeys on a release candidate, and follow appropriate workflows after deployment. Its evidence should arrive while the team can still act on it.
The user who comes back
A fresh account that can create a report tells us something useful. A returning account that can open an old report, preserve its filters, and share it under changed permissions tells us something else. The second journey tests whether the product still makes sense over time.
Our longer-term bet is on persistent synthetic users: agents carrying user history, intent, permissions, preferences, and prior outcomes across runs.
Consider a synthetic user with a project and an invitation already in progress. Their next run should be able to continue that journey after a release. If they get stuck, a later run should be able to revisit the same conditions after a fix.
- 01 / Before releaseInvite received
The user has an existing account and an invitation to a new workspace.
Intent saved - 02 / After releaseWrong workspace
They accept the invitation but cannot reach the project they were invited to.
Failure recorded - 03 / After a fixJourney revisited
Recreate the failed starting state and check access to the intended project.
Fresh evidence
Stateful tests already cover parts of this problem. The opportunity with agents is to combine that preserved state with exploration: responding to a changed interface, trying a reasonable alternative, and investigating an unexpected result.
That is why I think the most valuable part of an agent swarm is the history it can accumulate. More agents give us more attempts. Useful memory connects those attempts to what happened before.
Over time, the question becomes: can this user, with this history, still accomplish their goal in this version of the product? That moves verification toward continuous behavioral simulation.
The memory has to remain tied to evidence. We need to know which environment and version were exercised, what state the user started with, what they tried, and what actually happened. A previous success cannot stand in for a current check. An ambiguous result needs to stay ambiguous until we can resolve it.
When a reviewer is needed
Suppose a team ships ten times as many changes. It does not automatically gain ten times as much time to inspect them. Someone still has to understand the intent, exercise the product, and decide whether the result is good enough.
That makes attention a design constraint for verification itself. A swarm that produces hundreds of loosely described concerns gives the team another queue to read. It has to help people reach a decision.
The useful handoff is specific: this user tried this task, on this version, under these conditions, and here is the evidence. Here is what remains unclear. Here is the decision that needs you.
- User goal and starting state
- Version, actions, and observed result
- Reproduction steps and uncertainty
- Is the behavior intentional?
- Does this failure block the release?
- What should success mean?
A repeated failure may need an engineer and a reproducible report. A changed permission rule may need the product owner to confirm the intended behavior. A successful task with an awkward workaround may need a designer’s attention. An agent reaching the end of a journey does not mean the journey was easy.
Human review becomes more useful when the reviewer arrives with context and a decision to make. The system should handle repeatable investigation and surface uncertainty, so people can spend their time on consequences, intent, and trade-offs.
What we are building Composal for
Composal’s starting point is agents using the product to exercise real workflows and edge cases. The direction is a verification process that learns from the product’s history and makes the next release easier to evaluate.
Synthetic users can show that a journey works under particular conditions. Real customers tell us whether that journey is useful, understandable, and worth returning to. Their behavior and feedback have to shape the goals we ask agents to pursue. Product correctness is an ongoing responsibility, not a substitute for learning what customers need.
CI and CD helped make integration and delivery repeatable. We want to make evidence of user success a routine part of shipping, too.
That is the third loop: Continual Agent Verification, with human attention focused where it matters.
If your team is producing changes faster than it can confidently verify them, talk to us about Composal.