I asked OpenHands what it'd take to let folks exte...
# proj-architecture
w
I asked OpenHands what it'd take to let folks extend the agent-server and CLI with custom code for driving conversations. E.g. if I defined a multi-agent workflow for TDD, or waterfall, or planner/implementer/critic; or if I defined custom python tools; or if I wanted to hook in new python logic in general--how could I still use the same familiar CLI interface? Attached is an RFC for how this might work. You could write
./waterfall.py
, then run
openhands --strategy=./waterfall.py
or
agent-server --strategy=./waterfall.py
to trigger the custom logic
l
Interesting! But would hooks be sufficient for this? It seems like maybe it could just be a hook with no code changes to the current code?
b
Technically, strategies work like switchers based on configs/env/state. For the simple case (which covers 90% of what this RFC describes), a YAML config is more accessible than a Python ABC and it can grow into an immutable standard:
Copy code
# waterfall.yaml
name: waterfall
description: "Design → Code → Test pipeline"

agents:
  designer:
    description: "System architect"
    system_prompt: "You are a system architect. Output a design doc."
    tools: []

  coder:
    description: "Implementation engineer"
    tools: default

orchestrator:
  tools: [delegate, ...default]
  system_prompt: |
    Orchestrate a waterfall process:
    1. Delegate to 'designer' for architecture
    2. Delegate to 'coder' to implement the design
    3. Verify the result
Copy code
openhands --strategy=./waterfall.yaml --task "Build a REST API for ./specs_api.j2"
The loader reads YAML, calls register_agent() for each entry, builds the orchestrator with DelegateTool - same result, zero Python knowledge required from the user. At the same time, I support the idea of Python as a fallback for developers who need custom logic beyond what a config can express. Re: hooks - they won't help here. Hooks are guards and observers, not multi-agent workflow orchestration. But the idea to use guardrails as concept is cool.
I found that yaml is easier to control than python code (I tried with 12 agents, just tbm) for smth big also.
w
The main issue I'm trying to solve here is that folks are building lots of custom stuff with the SDK, but then they have no interface into viewing the underlying trajectories/conversations, or for triggering them The goal here would be to create a bridge between custom SDK code (which is already being written) and our existing interfaces
👀 1
👍 1
c