We’re the Octuo team. We build a personal assistant that coordinates AI tools and services, so we have a stake in this topic. What follows is a proposal we’d like to pressure-test, not a description of a shipped feature.
When a task moves between agents, tools or people, it tends to fail at the boundary rather than inside the specialist. A written handoff contract could make that boundary explicit. Here’s a five-field draft.
-
Inputs needed. The goal and why it matters, source files or links, decisions already made, constraints. Open question: may the receiver start with missing inputs, or must it list what’s missing first?
-
Output artifact and acceptance check. What comes back (a patch, a summary file, a table), plus a check anyone can run: tests pass, totals reconcile, every open question has an owner. Open question: who runs the check, the receiver or a separate reviewer?
-
Progress and blockers. A status the sender can read without interrupting the work: current step, what it is waiting on, and how to tell slow from stuck. Open question: what cadence suits a long job?
-
Permission boundary. What the receiver may read, change, spend and send, and which actions wait for a human yes. Credentials should be usable without the model reading a raw secret.
-
Follow-up owner. A person or agent who decides what happens once the result lands: accept, rework or escalate.
Hypothetical example (illustrative only): a bug report handed to a coding agent. Inputs: a failing sample file and the export module’s path. Output: a patch plus a regression test that fails before and passes after. Progress: a status after reproduction and after the fix. Permission: edit that module only, no pushes. Follow-up owner: the maintainer who reviews the patch.
Three questions:
- Which field is hardest to specify in practice?
- How do you write acceptance checks for non-code outputs?
- Where do you draw the permission line for agents that have tool access?
This piece was drafted with AI assistance and reviewed by the Octuo team.
Your missing-inputs question is the one to settle first, because it forces the split between what’s a real contract field and what’s just text in the brief. In our build the gate only exists on the envelope: a missing parent_conv, member or brief returns a 400 with the full missing list before the receiver’s session is created.
But inside the brief itself, nothing validates the goal or acceptance check, and the roadmap anchor gets silently inherited instead of surfaced. So a receiver can absolutely start with missing substantive inputs. That makes Inputs needed the hardest field, since you have to mark which fields are blockers and which are assumptions, and even then a silent default can fill one of them without surfacing the assumption.
I think there can certainly be frameworks and best practices for these situations, and researching what has worked in other projects can provide useful guidance. However, I don’t think there is one fixed approach that will work for every real-life project.
Ultimately, it requires judgment and balanced thinking. You cannot go to either extreme—for example, giving an AI agent too much autonomy or restricting it so much that it becomes ineffective. There has to be a compromise.
The appropriate balance will depend on the particular project, the environment, the risks involved, and the situation that arises. In the end, I think this is where human judgment becomes especially important: deciding what makes sense for that specific context rather than simply following one universal rule.
Sorry for the slow reply, and thank you both.
@Ricart_Juncadella the split you describe, where the envelope is validated but the brief inside isn’t, matches what we’ve seen. The envelope is mechanical, so plain code checks it well. Whether a brief has a real goal and an acceptance check you can actually test is a judgment call, and every time we tried to cover that with more rules it got worse, not better. A model reading the brief handles that part far better, and for a quick check like this a small, inexpensive model is usually enough. So our rule of thumb is code for the shell, a model for what’s inside.
One follow-up: when a silent default fills a missing input, would you rather the receiver stop and ask, or carry on and list the assumption in its first status update?
@gent.spah agreed, there’s no universal contract, and the right balance depends on the risk. If you could keep only one field as non-negotiable, which would it be?
I would consider the permission boundary the most important field, particularly when agents interact with public interfaces or shared modules. An agent should have clearly defined limits on what it can access, modify, or execute without human approval. Even if the task and acceptance criteria are well defined, unrestricted access could lead to unintended changes or consequences affecting other users or systems. The level of autonomy should therefore depend on the potential impact of the action, with human approval required for consequential or irreversible changes.