This issue is created to review the current Canvas AI architecture based on discussions during DrupalCon Chicago and identify how we can improve performance, cost, and user experience.
In the current architecture, the orchestrator agent is the least informed part of the system. Its only responsibility is deciding which sub-agent to call for a task.
It does not know:
Because of this, most of the actual work and understanding is pushed to sub-agents.
There is also inefficiency in how input is handled. If a user provides a large input (for example ~1000 tokens), the orchestrator has to repeat and pass the same content again when invoking a sub-agent. This increases token usage and cost.
The current flow also has UI issues. When a sub-agent completes a task, its response is shown in the chat. Then the orchestrator returns a similar response again. The page updates only happen after the final orchestrator response. This creates duplicate messages and makes the flow confusing.
When building a page, the sub-agent generates a large YAML structure for components. If there is any mistake (invalid prop, missing required field), validation fails and the whole response is generated again. There is no caching or partial retry, which increases response time.
The orchestrator should be able to see and understand the system better.
It should have access to:
The agent should create a plan for the end user for complex tasks, such as creating a full page, with real-time feedback on what’s happening. Some related issues:
#3547238: Follow up from 3531000 - Create a true plan for the end-user
#3546907: Implement Two-Step Agentic Flow with Planning Phase
Sub-agents should only focus on doing a specific task (for example creating or updating part of a page) without needing to handle everything.
Instead of generating the entire page in one go, the system should move towards smaller steps where parts of the page are created and shown as they are ready.
Context passing should also be reduced so we are not repeating the same large inputs across steps.
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | Screenshot from 2026-04-10 14-43-01.png | 92.91 KB | akhil babu |
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
compare
Comments
Comment #2
akhil babuComment #3
akhil babuComment #4
akhil babuComment #5
akhil babuComment #6
akhil babuComment #7
akhil babuComment #8
akhil babuComment #10
akhil babuComment #11
d34dman commentedHi @akhil babu,
I ran into similar issues during early iterations while working with Agentic workflow builder for FlowDrop. Even though its a different domain, the failure modes are quite close:
- hallucinated field names,
- half-applied state changes,
- prompt-injection through user content (un-intentional miss-guide),
- runaway token costs as state grows
- what i like to call "what ID did you just create?" round-trip problem (kind of catch-22 situation)
So a lot of engineering went into designing the system around the prompt.
What worked for us (its not perfect, but we achieved orders of magnitude improvement over pure agentic system)
- Choosing the right LLM output format for use (a Domain Specific Language instead of JSON tool calling)
- Slim context aggressively by supplying information on need to know base
- Defend against prompt injection in chat history
- Define predictable identifiers, so the LLM can plan multistep changes in single response without round trips
- Making agent action atomic and reversible
- "Manually encoding priorit failures into system prompt"
If there is enough interest in the solution, i am available to collaborate on this front.