>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3563389. --> Reported by: [marcus_johansson](https://www.drupal.org/user/385947) >>> <p>[Tracker]<br> <strong>Update Summary: </strong>[One-line status update for stakeholders]<br> <strong>Short Description: </strong>[One-line issue summary for stakeholders]<br> <strong>Check-in Date: </strong>MM/DD/YYYY<br> <em>Metadata is used by the <a href="https://www.drupalstarforge.ai/" title="AI Tracker">AI Tracker.</a> Docs and additional fields <a href="https://www.drupalstarforge.ai/ai-dashboard/docs" title="AI Issue Tracker Documentation">here</a>.</em><br> [/Tracker]</p> <h3 id="summary-problem-motivation">Problem/Motivation</h3> <p>An Agent is in its essentials is just a system prompt and tools that loops over tool usage until its finished. <a href="https://github.com/huggingface/smolagents">smolagents</a> is an example of this in its barebone format.</p> <p>However what makes an agent stable is the possibility to enforce certain rules, restrictions and flows on what the agent sees in specific states/loops.</p> <p>Some examples of this could be: </p> <ul> <li>You might want to keep the system prompt small and concise for specific loops.</li> <li>You might want a tool to always run before another tool.</li> <li>You might force that a tool should run.</li> <li>You might want to end the agent loop when a specific tool is run.</li> <li>You might want to change the tool description for a specific agent or even a specific loop.</li> <li>You might want to hide a tool on a specific loop.</li> </ul> <p><strong>Note: </strong> - these are just examples, and what is important for the core to handle should be scoped out.</p> <p>Currently all this is hardcoded in the agent form and in the agent runner. We have added some generic rules and restrictions that we have seens helps in almost all cases of creating agent. </p> <p>However, we can assume that we do not know everything that is important for the end-user and for specific agents, so the idea is instead:</p> <ul> <li>Move out this and make it a formable and configurable plugin system.</li> <li>Add events to the most important parts of the loop (we already have them) - pre-AI inference, post-AI inference, pre-tool execution, post-tool execution.</li> <li>Make it possible for these plugins to hook into to these events.</li> <li>Make it so the plugins has weighting per event, so we know when they run in order (maybe later controllable).</li> </ul> <p>For programatic agent, they can choose to configure these plugins or they will just have access via methods to the events and can programatically do their changes there.</p> <p>I will scope out this issue, if people in general thinks it sounds good. We might need to run through UX as well.</p> <p>The idea is heavily based on search api processors.</p>