I ran Matt Pocock's improve codebase architecture skill on agent canvas. It found 6 architectural improvement opportunities 🔦 Here are the github issues: github.com/OpenHands/agent-canvas/issues/1537 / github.com/OpenHands/agent-canvas/issues/1538 / github.com/OpenHands/agent-canvas/issues/1539 / github.com/OpenHands/agent-canvas/issues/1540 / github.com/OpenHands/agent-canvas/issues/1541 / github.com/OpenHands/agent-canvas/issues/1542

out of curiosity, what LLM did you use?

opus 4.8!

Nice. I’m having GPT-5.5 make a pass and post a reply. (We can consider it or discard it; I’m just curious and for me, it helps to stress the proposals a bit typically, to feel the right code design.)

Addressed feedback and updated all issues! I'm a fan of the agent debate approach where one agent reviews another's work. I do feel it generates an overall better result

LLMs have no taste, you know how they say. But they know all the tasteful options! And different LLM families may incline more to notice this or the other. Thank you for this!

I agree, good idea to refine these with multiple models' feedback

It's 10x more important with agents, than it used to be in the Before Times(tm) 😅, that is, before agents got good enough. Because they do stuff alright, but man do they do hacky stuff, useless stuff, redundancies too

Yes there are a bunch of hacky roundabout ways to get to a goal. The agents will probably find it with their persistence 😄

If we allow them! This is why, on agent-sdk in particular, we have implemented a bunch of guardrails. They’re workflows or AGENTS.md/docs/skills, so deterministic and non-deterministic alike, to keep boundaries in place. I think that might be a significant part of what we need to do everywhere…

Think you could create some github issues in agent canvas to replicate some of the relevant boundary checks? If there is an issue, it is more likely to be worked on 🙂

Good point, idk, but your issues are already great! e.g. the first issue, 1537, is exactly this type of boundary: no imports from components to

/api

, it’s the wrong dependency direction.

I haven't spent much time in the SDK but seems like I should start to check out the guardrail setups there 🙂