So it was user error; but this raises more questions for me, I do wonder why do we have a

default

agent profile that is not a … default OpenHands agent, I mean it’s not a workable profile

canvas itself first creates

default

and then adds to it the

terminal

and

file editor

tools manually, from what I understand

cc @strong-ice-84145 Please correct me if wrong, is my agent fooling me here, or is this just strange?

@calm-artist-7206 I had closed the PR you approved but just reopened it. Perhaps worth merging + fast release just to implement a fix.

Let's merge as is

Do you need anything?

On a side note, on that newer canvas UI, I didn’t see the LLM dropdown anymore. I loved it… 😭 Maybe the way we can do here is like: • user has by default the LLM profile dropdown • any LLM they define/choose applies to an unnamed/default agent profile • a checkbox to enable agent profiles • if enabled, maybe add the agent profiles dropdown

actually closing 4078 + adding a fix on the other PR. Will let you know when should review, Then we can merge + cut a release

it's the same tool, why support the legacy variant, apart from maybe old conversations for a time? But even for old conversations, we might have now in place some code that makes them load, even though the old tool is unavailable

@calm-artist-7206 - SDK PR: github.com/OpenHands/software-agent-sdk/pull/4030 - Canvas PR: github.com/OpenHands/agent-canvas/pull/1650 Compared with main, the SDK PR makes agent-server the authority for deployment-default tools, exposes them through /server_info.default_tools, and applies them when a profile has tools: null. The Canvas PR registers canvas_ui as a managed agent-server default, consumes the server-reported defaults, and launches the selected profile directly instead of rebuilding an inline substitute. The resulting contract is: null inherits agent-server defaults plus canvas_ui, [] means no tools, and a specific list is used exactly. The SDK PR also migrates untouched legacy default profiles that were incorrectly seeded with [].

but

extra_default_tool

is annoying, trying to remove it

It's a choice of agent-canvas to send in addition, if that makes sense?

Do we have something like, a design doc for Agent Profiles?

If not, could we make one? Lately I got into the habit to ask the agent to make up an HTML page, document x feature, and it pushes it to enyst.github.io, because it's just easiest, nothing to set up really

Maybe something like that, or apparently github has a "htmlpreview" subdomain that can be used on the fly

Just so we can read in a more humanly-readable format, what are we doing 😂

wdyt of github.com/OpenHands/software-agent-sdk/pull/4030/…/c284488b6948… adding a boolean "is_default" during tool registration

but that commit looks pretty good

Could we make a page documenting the intended behavior, and maybe the high level arch components and their responsibilities?

You know best what you want it to talk about

I thought we had already replaced the

canvas_ui

old python implementation with the new

.json

client-side tool definition, but my agent - and Ai Vong’s agent - are saying it’s still in canvas: • we replaced it in agent-sdk • but agent-canvas still uses the old python definition I opened a PR to try to kill it… https://github.com/OpenHands/agent-canvas/pull/1797 Unfortunately it seems it cannot be immediate, old conversations have the python classes and would probably fail to deserialize. What might… help, maybe, with the profile… is that this is a client-side tool that should only send a minimal definition? Or maybe it doesn’t make a difference for your PRs, you still need to send it 🤔

I didn't know that client_tools existed! My SDK PR uselessly reimplemented, happy to simplify

merged! cutting a release now