add support for agents

[adilhafeez]

Update arch_config to define agents. You can now define agents and combine them in a listener using agents and listener keys. Here is a sample config defining simple rag agent,

agents:
  - id: query_rewriter
    url: http://host.docker.internal:10500/v1/chat/completions
  - id: context_builder
    url: http://host.docker.internal:10501/v1/chat/completions
  - id: rag_agent
    url: http://host.docker.internal:10502/v1/chat/completions

model_providers:
  - model: openai/gpt-4o-mini
    access_key: $OPENAI_API_KEY
    default: true
  - model: openai/gpt-4o
    access_key: $OPENAI_API_KEY
  - model: ollama/llama3.1
    base_url: http://host.docker.internal:11434

model_aliases:
  fast-llm:
    target: gpt-4o-mini
  smart-llm:
    target: gpt-4o

listeners:
  - type: agent_listener
    name: agent_listener_1
    port: 8001
    router: arch_agent_router
    agents:
      - id: rag_agent
        description: virtual assistant for device contracts for simple queries
        filter_chain:
          - query_rewriter
          - context_builder

[salmanap]

I haven't looked at the demos. Those weren't as important as the core logic for agents and agent_filter_chains. Overall the structure looks really good. But lets discuss the few comments below. I think we have an opportunity to harden this a bit more.

[salmanap]

don't we need model_providers || llm_providers as a required property?

[adilhafeez]

It is possible to have an agent without llm_providers. Same way we can have prompt listener without llm_providers.

[salmanap]

Technically that's true. Should we throw a warning?

[adilhafeez]

thanks @salmanap for reviewing - have responded to your PR. Will update the code by noon.

[salmanap]

Thank you for making all the changes. This PR looks good - just one thing: we need to have a story on filter chain failures, recovery and that whole workflow looks like. We need some basic work on that.

Second, I think given that we don't want to publicly release the feature until full support for MCP, should we pull the demos out of this PR to not confuse developers on our current v. new config. Because they will see both in the demos and will scratch their heads. The second PR is needed anyways to complete the feature on routing and orchestration.