Context
Architecture discussion from v0.2 planning session.
Problem
When 3+ agents collaborate on a shared .vek repo, who coordinates merges, how are task dependencies expressed, and how do you get a global view?
Proposed Approach: DAG-as-Protocol (Mode 3)
Use special tool name conventions to express agent coordination within the existing DAG no new mechanisms needed.
Convention
__delegate__ assign task to another agent
__report__ return results from delegated task
__sync__ checkpoint across agents
Possible new APIs
vek.watch(branch, callback) subscribe to new nodes on a branch
- Per-branch log already supported via
vek.log()
Why not now
Need real user feedback first. Ship demo, get users, see how they actually use vek in multi-agent setups, then design based on evidence.
Alternatives considered
- Coordinator Pattern central agent merges all branches
- Event Bus agents subscribe to each other's branches
- DAG-as-Protocol convention-based, no new mechanism (preferred)
Status
Parked. Revisit after first user feedback from HN launch.
Context
Architecture discussion from v0.2 planning session.
Problem
When 3+ agents collaborate on a shared .vek repo, who coordinates merges, how are task dependencies expressed, and how do you get a global view?
Proposed Approach: DAG-as-Protocol (Mode 3)
Use special tool name conventions to express agent coordination within the existing DAG no new mechanisms needed.
Convention
__delegate__assign task to another agent__report__return results from delegated task__sync__checkpoint across agentsPossible new APIs
vek.watch(branch, callback)subscribe to new nodes on a branchvek.log()Why not now
Need real user feedback first. Ship demo, get users, see how they actually use vek in multi-agent setups, then design based on evidence.
Alternatives considered
Status
Parked. Revisit after first user feedback from HN launch.