[Agent] Introduce capabilities

[Guikingone]

Q	A
Bug fix?	no
New feature?	yes
Docs?	yes
Issues	--
License	MIT

This PR aims to introduce the support for "policies" at the Agent level, Policies are a way to enable/disable features in agents (think of it like stamps on Messenger messages` or "feature-flags").

This PR is an extension of a discussion with @chr-hertel last week about the refactoring of Agent, the main goal is to allow adding new features depending on the configuration of an agent and the enabled policies (for example, we might want to enable SpeechPolicy to add the support for Speech as implemented in #943, it can also help the introduction of Evaluator later and many more).

For now, two policies are implemented (for demo purpose and tests), the configuration is done and tested, same for the agent implementation.

[chr-hertel]

okay, thinking out loud here ...

---

let's collect some use-cases here:

• delay (like implemented, not sure why we need that tho?)
• stt-tts sandwhich (yes, we want that)
• evaluation (would it really be within the agent?)
• some i18n feature maybe?
• guardrails?
• yolo mode? skipping all confirmations, see [Agent] Introducing foundation for human-in-the-loop mechanism for tool calling #1548

if i get it right, the main difference to processors is, that users by design influence it per agent call, right?
looking at the code here it feels a bit redundant to have those extension points just next to each other, but i like the more structured invokation

so i would configure an agent with a SpeechPolicy, and i would configure the usage of it via state object in $policies while calling the agent

why "policy"? doesn't click with me directly .. what about "behaviour"?

---

my bottonline:

• interesting!
• can we streamline with processors extension point?
• can we bring in more examples?
• naming?

[Guikingone]

delay (like implemented, not sure why we need that tho?)

Just for example here, can't implement the stt-tts one without this PR 😄

evaluation (would it really be within the agent?)

Input/Output evaluation as we might have a situation where you're configuring the Evaluator (name to refine TBH) to evaluate certain aspects of them then you're using a "policy" to override the "rules" applied at runtime (like groups for validation).

some i18n feature maybe?

Could be something to explore.

guardrails / YOLO mode

Why not 😄

if i get it right, the main difference to processors is, that users by design influence it per agent call, right?
looking at the code here it feels a bit redundant to have those extension points just next to each other, but i like the more structured invokation

Yes, kind of, "policies" are here to be like stamps on messages or "feature-flags", if you take the speech one, the current implementation is not perfect as once it's configured, all agents have it, thanks to policies, you can decide at runtime which agent will receive specific speech configuration (and you can even change after defining them) depending on a particular situation.

The name is open to debate, I used policies as I mentioned them during our conversation on the agent, after thinking about it, maybe Capability is more accurate (as you're allowing an agent "to do something"), it's already used in the Platform but is that really an issue if the name is used twice? Open to debate 😅

can we streamline with processors extension point?

Actually yes, one solution might be to define a Policy|CapabilityInputProcessor and interact with the Input|Output in the processor, as they're actually called at the same moment, not a big issue.

can we bring in more examples?

Actually, I might have another example for policies/capabilities/nametodefine with "delegating" agents, could be something to explore on this PR (not a load of work to do).

[OskarStark]

Should be mentioned here IMHO: https://symfony.com/doc/current/ai/index.html#key-features

[Guikingone]

Hi @chr-hertel @OskarStark 👋

Just pushed a refactoring of "policies", name is now Capability and is improved on the API (agent-aware, improvement on public interfaces, etc), I also worked on preparing the pipes for #1548, I let you review it when you have time.