Designing for an agent as a team member, not a tool
If an agent is doing a real chunk of the work, it needs the things any team member needs: a defined role, clean handoffs, and a trail of what it did and why. This note, circulated inside Redomic, sets out how we are trying to design for that.
When an agent takes on part of a workflow, it stops behaving like a tool that is picked up and put down, and starts behaving more like a member of the team. Not a person, but no longer just software either. The design questions change accordingly. You do not write a job description for a hammer; you do for a new hire, and an agent doing real work sits closer to the second than the first.
So we have been designing agents the way you would design a role. What is this one responsible for, and what is explicitly not its job? Where does the work pass to it, and where does it pass back? And when someone asks later what happened, can the agent account for what it did in a way a person can read and check? These are ordinary questions about working with a colleague, applied to something that is not one.
What we are working through
- How do you specify an agent's role tightly enough that its boundaries are clear to the people around it?
- What makes a handoff between a person and an agent clean rather than a place where work quietly falls through?
- What does an audit trail need to contain for a person to trust, and if needed contest, what the agent did?
- Where should an agent stop and defer to a person, and how is that boundary made legible rather than implicit?
Open questions
- Can a role be specified well enough that two teams would build the same boundaries from it?
- What is the right way for an agent to hand back work it is not confident it should be doing?