Road to Symfony AI v1.0

[chr-hertel]

Of course, we want Symfony AI to become a stable and reliable set of packages, complying to known Symfony standards, like the BC promise. This will only be achieved with the release of v1.0.

Reaching that level of reliability is important for adoption and using Symfony AI in production without patching your code all the time.

When going with symfony/ai instead of integration into symfony/symfony we decoupled releases deliberately since we're still figuring out what we need to build. And as long, as we are aware of flaws, that make BC breaks necessary, it would create extra effort to provide a BC layer - slowing is down.

However, we want to create transparency, where we are on this road, for users to follow along.
This issue tracks high-level items, that need to be resolved until we can tag a v1.0 of Symfony AI.
When all items are tackled, a feature freeze around 4 weeks will kick in, to stabilize the codebase.

• This uses the MoSCoW method for priotization. Items are up for discussion.
• Items are labeled as MUST if impact to component API is expected.

Open to resolve

• Platform Component
  • MUST Solve dynamic model catalogs decoupling package lifecycle of model lifecycle
  • MUST Better stream handling for exposing thinking/reasoning as well
  • MUST Better handling of multi-modal responses (generated speech, images or video)
  • SHOULD Meaningful adoption of capabilities/tasks, validation and routing in ModelCatalog/Platform
  • SHOULD Remote tool support
  • COULD Twig message template support
  • COULD Streamlined Error Handling
  • COULD Streamlined JSON to data conversion
• Agent Component
  • MUST Redesigned API to tailored Agent API instead of being a slim Platform decorator (name + instruction + tools + input + options)
  • MUST Introduce traces to come out-of-the-box instead of custom
  • SHOULD Built-in support for integration with messenger & workflow component
  • SHOULD Integrate hand-off into one universal Agent
  • SHOULD Default approach to human-in-the-loop (demo only?)
  • SHOULD Sources/traces support across built-in tools
  • SHOULD Message template support for SimilaritySearch (and others?)
  • COULD Context to memory (summarization)
  • COULD Prevent tool calling loops
  • COULD Tool classifier (read vs write)
  • COULD Validation on top of structured output
  • COULD MCP support, agent acting as
• Store Component
  • MUST Universal storage component supporting all use-cases instead of components/bridges per use-case
  • MUST Introduce retrieval extension points for features like multi-vector query or reranking
  • MUST Work out-of-the-box with entities/repositories - unified store vs. additional store
  • MUST TBD Extract Retrieval into separate component
  • SHOULD More loaders & transformer implementations (web, folder, pdf, word, json, ...)
  • COULD Generalize common options when querying
• Chat Component
  • MUST Handle multi-user conversations
  • SHOULD Streaming integration
• AI Bundle
  • SHOULD Panel split into components (platform, store, tools, and agents), but unified trace for Agent

Known, but not needed for

• Agent/Model evaluation framework
• A2A or A2UI/AG-UI support
• OTEL integration
• More bridges

[julesdig]

Hi @chr-hertel ,

I’ve been following the Symfony AI roadmap and saw the open items toward v1.0 (especially the Platform / Agent parts).

I’d really like to contribute to Symfony AI as an open-source contributor.
I’m motivated to code, but I’m not entirely sure where the best entry point is right now.

Would you recommend starting with a specific SHOULD / COULD item, or a particular component that would benefit most from contributions at the moment?

Happy to work on a concrete, well-scoped task.

Thanks!

[OskarStark]

Welcome and thanks for joining us on this journey :airplane

I think

SHOULD More loaders & transformer implementations (web, folder, pdf, word, json, ...)

is a good starting point with a smaller scope. Maybe start with the folder or json one

[julesdig]

@OskarStark Thanks for the suggestion!

To make sure I’m aligned: I started working on a JsonLoader following the same approach as the existing TextFileLoader.

The idea for now is:

• JsonLoader reads a JSON file from disk (same checks as TextFileLoader)
• validates that the file contains valid JSON
• and creates one TextDocument from it, using the JSON content as the document content

So conceptually, it’s the same as TextFileLoader, except the source is JSON instead of plain text.

What I’m not fully sure about yet is the next step:

• whether the loader should already extract a specific text field (e.g. "content")
• or if it’s expected that the JSON stays as-is and the transformation / chunking into text is handled later by a Transformer

For a first contribution, would you consider a simple JsonLoader (JSON file → TextDocument with raw JSON content) acceptable, similar in spirit to TextFileLoader?

Happy to iterate based on your feedback.

[chr-hertel]

@julesdig only doing the same like the TextFileLoader would be too little, but let's move the discussion to #1404