Hey! 👋 Just some thoughts. I was looking inside the docs, and I noticed that the software-engineer-sdk is 4 separate packages (

openhands-sdk

,

openhands-tools

,

openhands-workspace

,

openhands-agent-server

), which are already are already well documented with guides and examples, but the API Reference only covers

openhands.sdk.*

. The multi-package reality isn't clearly reflected in the docs structure. We could do:

sdk/api-reference/
├── core/           # openhands.sdk (what we have now)
├── tools/          # openhands.tools (BashTool, FileEditor, browser-use...)
├── workspace/      # openhands.workspace (Docker, Apptainer, Cloud...)
└── agent-server/   # openhands.agent_server (Python API + OpenAPI)

Nav would mirror this with 4 groups. Moreover, the guide are mixed. A guide like

agent-browser-use.mdx

is under "Agent Features" but it's really about

openhands.tools.browser_use

. Similar as above, we could have

sdk/guides/
├── core/
|  ...
├── tools/
│   ├── index.mdx          # "All about openhands-tools"
│   ├── bash-tool.mdx
│   ├── file-editor.mdx
│   ├── browser-use.mdx    # move from agent-browser-use
│   └── ...                # move from top level
├── workspace/
│   ├── index.mdx          # "All about openhands-workspace"
│   ├── docker.mdx
│   ├── apptainer.mdx
│   └── cloud.mdx
└── agent-server/

or it is adding too much complexity in the docs?

General idea seems good to me as long as we don't change how these pages are displayed in the doc site. My only worry about changing the structure would be - it can break the old links lolsob But you can always setup redirection in docs.json, so if we do this carefully, it should be ok

I really like the idea of a better organized guides section. I've been thinking about reorganizing for the main documentation root as well but have not gotten into the sdk much. Some of the content in /core might be good to keep in the guides root for visibility like hello world.

Just thinking that the 2 are not really alike • the Python API and the OpenAPI refs can have the form of the underlying packages/modules/etc • the guides are a bit less tied to the underlying implementation, they could be organized in new categories as long as we think that from user perspective it looks better = it's easier for them From that pov, browser use is an Agent Feature 😅