Part II. The team: people and agents
If it isn't written down, everyone works with their own agent
Agreements between people and agents: vibe coding or specs, autonomy, Daily Scrum and Sprint Retrospective
Four ways of working in a team of six
Three months after they started using agents, GymApp had four ways of working with them. Germán wrote a spec before every change and reviewed, line by line, what the agent gave back. Unai told the agent in the chat what he wanted, tested the result and kept whatever worked. Aitana used the agent for everything, including the app's texts.
And Celia had started generating screens that sometimes ended up in production without anyone looking at them.
Nobody had decided this. It worked until Unai went on holiday. Aitana had to change the waiting list, which he had built, and she looked for how it had been designed. Nothing was written down. There was the code, which worked, and a conversation with the agent that only Unai could see. She asked her own agent for the change, and it rewrote the logic its own way. On Friday, two members got the same spot.
Olga took it to the Sprint Retrospective with a single question: how do we work with the agents? Four answers came out, one per person.
Without an agreement, everyone works with their own agent
A team without agents already had agreements, even if it never wrote them down: how code is reviewed, when it is integrated, what done means. With agents, each person also has their own way of working with the machine, and that way is invisible. It doesn't show up on the board or in the code. It shows up when something breaks.
That is why collaboration between people and agents can't be left to each person's habits. It has to be written down. A working agreement with agents captures what an agent can't work out on its own and another person needs to know. It isn't a company policy or a manual.
It is one page that the team writes, follows and changes, like the team agreements for using AI (in Spanish) that many teams already know, applied to daily work with agents.
Vibe coding to explore, specs for what stays
The first decision in the agreement is the way of working. There are two, and both have their place.
Vibe coding (in Spanish) means asking the agent for what you want in natural language, testing what comes out and asking again until it works. It is very fast and very useful for exploring: a prototype to show five members, a technical test to see whether something is possible, a single-use tool. Its problem is that the intent isn't recorded anywhere.
What remains is the code, which says what it does, and a conversation nobody else sees, which said why. That is what happened to Unai, and what happened to me with my website, as I explain in the introduction.
Spec-Driven Development (in Spanish) (chapter 5) reverses the order: first a small spec with examples, then the agent, then a review against the spec. It is a little slower at the start and much cheaper later, because the intent is written down next to the code. Anyone, and any agent, can read it six months from now.
The difference shows most when the work leaves the team. Another team that wants to reuse something reads the spec, not your conversation with the agent. A new agent that has to change it starts from what was intended, not from what it guesses. And when several agents work at the same time, the spec is what makes their changes fit together.
For several teams to collaborate without stepping on each other, and for what has been built to scale, the way forward is the spec (chapter 18).
The agreement I propose is simple: vibe coding to explore, in the discovery track and for anything that will be thrown away; a spec for everything that goes into production. And one transition rule: if a prototype built with vibe coding is going to stay, its spec is written first, and then it is rebuilt or reviewed against it.
How far an agent goes without asking
The second decision is how much autonomy each agent has. At ITNOVE we settled it with three levels, which our three agents use:
- It does it and reports it. Anything that can be undone at no cost, that no customer sees and that involves no judgement call: adding a test, fixing a typo, preparing a report, leaving a draft. The agent does it and mentions it in its next report, along with how to undo it.
- It proposes and waits for a yes. Anything a user sees or that changes how something works, but can be reversed: a text on the website, a code change that alters a behaviour. The agent leaves the proposal with its supporting data and the exact change, and applies it when a person says yes.
- Only with an explicit OK. Money, personal data, third parties and anything that can't be undone: sending emails to customers, changing prices, deleting data. The agent gets it ready and never runs it on its own.
And one rule for doubts: if you don't know which level something belongs to, move it up one.
The levels don't measure how much you trust the tool. They allocate people's attention. If everything our agents do went through me, I would do nothing else. With the levels, small things get done on their own and are reported, and what reaches me is what really is a decision.
The agreement, on one page
With those two decisions made, the rest of the agreement fits on one page. This is the one I propose as a starting point; each team adapts it:
- How we work. Vibe coding to explore; a spec for what goes into production.
- What we give an agent and what we don't. Bounded, verifiable work, yes; deciding value, negotiating with people or accepting a risk, no (chapter 5).
- Autonomy. What it does alone and reports, what it proposes, and what it does only with an OK.
- Permissions. What it can touch, in which environments and with which data.
- Review. Who reviews what, the maximum size of a change submitted for review, and the maximum number of hours a day each person spends reviewing.
- Context. Where the instructions the agents read are kept, who changes them and how they are reviewed (chapter 14).
- When an agent gets it wrong. Fixing it isn't enough: we look for why it could happen and add whatever prevents it from happening again, whether that is a rule in its instructions, a test or an automated check.
- When this agreement is reviewed. Every few Sprints, in the Sprint Retrospective.
Point 7 is the one that has changed our way of working the most. Every failure that reaches production is fixed together with the strongest mechanism that stops it from coming back: first, make it impossible; if that can't be done, make sure it can't get in without a test stopping it; if that can't be done either, make it visible at release or the next morning.
A rule written in a guide is the last resort, because it is the easiest one to forget.
The Daily Scrum: what the agents did isn't read out loud
The Daily Scrum is one of the places where you can most clearly tell whether the agreement exists. Without an agreement, it fills up with the agents' reports, as happened to GymApp in chapter 13. With an agreement, it lasts fifteen minutes and follows this order:
- How are we doing towards the Sprint Goal? The usual question comes first.
- The review queue, from oldest to newest. The board is walked from right to left, as in Kanban (in Spanish): first what is closest to done. Work that has been waiting days for review is a team problem, not an agent problem.
- What the agents did, only if it affects the goal. The report arrives before the Daily Scrum, and one person, taking turns, has filtered it and brings only what changes something.
- What we give the agents today and who reviews it. No work is launched that nobody has time to review.
- Which decisions are waiting on a person. The Product Owner's, another team's, the ones that need an OK.
On some days it can be done in writing, if the team is distributed, but point 4 is worth talking through: it is where the day's attention gets allocated.
The Sprint Retrospective: how we work with them is reviewed too
The Sprint Retrospective is the other place. In addition to the Scrum Master's three questions (chapter 4), with agents it is worth looking at three pieces of data from the Sprint, which an agent can prepare:
- Which of the agents' proposals were rejected or had to be redone, and why.
- How long work waited in the review queue, and in front of whom.
- Which failures reached production, and whether they already have a mechanism to prevent them from recurring.
What comes out of this is an action like any other, with one difference: often the action isn't for the people, but for the agents. A change to their instructions, a better spec template, a new test, one permission fewer, a level of autonomy that goes up or down. Changing how the agents work is a team decision, and its place is the Sprint Retrospective.
What happened at GymApp
GymApp's agreement came out of that Sprint Retrospective and took up half a page. Unai kept using vibe coding for the prototypes Celia showed to members, and the waiting list finally got its spec, written by the two of them when he came back from holiday. Celia's screens started coming in as proposals, not directly.
And the first review of the agreement, two Sprints later, added a line nobody had foreseen: no agent changes a text that members read unless Celia reviews it.
In short
Collaboration between people and agents is either written down or it gets distorted. Vibe coding to explore and specs for what stays, because the spec is what lets other people, other teams and other agents understand what has been built.
Three levels of autonomy to allocate attention, a one-page agreement and two events where it is looked after: the Daily Scrum, which allocates review, and the Sprint Retrospective, which also changes how the agents work.
Try it this week
Ask each person on the team to write, in three lines, how they work with their agent. Put them side by side at the next Sprint Retrospective and write the one-page agreement based on what doesn't match.
The comparison between the two ways of working is in Vibe coding or Spec-Driven Development (in Spanish), and the Daily Scrum in general is covered in An effective Daily Scrum (in Spanish).