[Feature Request]: Reduce Complexity in Plugin Configuration Framework

[arjavdongaonkar]

Today, the configuration pivots on plugin names, with each plugin defining where and how it applies (via hooks, conditions, tags, etc.). While flexible, this model introduces certain complexities:

Each plugin declares where it applies.

plugins:
  - name: "ContentFilter"
    kind: "plugins.native.content_filter.ContentFilterPlugin"
    hooks: ["prompt_pre_fetch", "prompt_post_fetch"]
    priority: 100
    conditions:
      - prompts: ["customer_chat", "support_bot"]
        server_ids: []
        tenant_ids: []
    config:
      block_patterns: ["ssn", "credit_card"]
      mask_char: "*"

  - name: "LoggingPlugin"
    kind: "plugins.native.logging.LoggingPlugin"
    hooks: ["prompt_post_fetch"]
    priority: 200
    conditions:
      - prompts: ["customer_chat"]

1. Tracking Burden

• Each plugin must list all tools, prompts, and resources it applies to.
• As the number of plugins grows, keeping track of their applicability across multiple contexts becomes cumbersome.

2. Ordering Challenges

• Plugin execution order is controlled globally by priority.
• Maintaining a consistent processing pipeline across routes/tools requires careful coordination of priorities across all plugins.
• Debugging order-of-execution issues becomes harder as more plugins are introduced.

3. Global vs. Local View

• The current structure emphasizes plugins first, not the routes/tools they protect.
• To know which plugin runs for a particular route/tool, you must cross-reference multiple plugin definitions.

---

Route-Centric Organization (Pivot on Routes/Tools)

Instead of pivoting on plugin names, pivoting on routes/tools invocations could simplify configuration.

Each route/tool lists its filters/plugins inline.

routes:
  customer_chat:
    - name: ContentFilter
      mode: enforce
      config:
        block_patterns: ["ssn", "credit_card"]
        mask_char: "*"
    - name: LoggingPlugin
      mode: permissive

  support_bot:
    - name: ContentFilter
      mode: enforce_ignore_error
    - name: LoggingPlugin
      mode: enforce

Benefits

Route-Centric Organization

• Each route/tool is self-contained, listing its applicable filters/plugins inline.
• Easier to understand the complete processing pipeline for a given endpoint / tool.

Simplified Filter Ordering

• Execution order is explicit in the array sequence, avoiding global priority management.

Targeted Configuration

• Each route can have a completely different filter/plugin combination.
• Conditional logic is built into route matching instead of being spread across plugin definitions.

Operational Simplicity

• Adding/removing filters for a route doesn't affect unrelated routes.
• Route-level changes are isolated, safer, and easier to test.

Clear Visibility

• Direct mapping between API endpoints/tool invocations and their processing steps.
• Faster onboarding for new operators—just open the route config and see everything at once.

---

Industry Precedent

Spring Cloud Gateway uses a similar route-centric model:

spring:
  cloud:
    gateway:
      routes:
        - id: createUser
          uri: http://dev.something.com
          predicates:
            - Path=/api/createUser
            - Method=POST
          filters:
            - name: MockExtractSomethingFilter
            - name: TokenAuthenticationFilter
        - id: updateUser
          uri: http://dev.agentpro.com
          predicates:
            - Path=/api/updateUser/**
            - Method=PUT
          filters:
            - name: MockExtractSomethingFilter
            - name: TokenAuthenticationFilter
            - name: RBACAuthFilter
                args:
                  requiredPermissions: UPDATE_USER
            - RewritePath=/api/updateUser/(?<UniqueCode>.*), /api/updateUser/${UniqueCode}

---

Questions

1. What drove the original decision to use a plugin-centric model?
2. Are there specific Context Forge use cases where plugin-centric configuration provides clear advantages?
3. Would a route-centric design scale better as the plugin ecosystem grows?
4. Could a hybrid approach address concerns from both models?

---

Note: This is a proposal for discussion. The goal is to evaluate whether a route-centric organization would improve operational clarity and maintainability.

[terylt]

Hi @arjavdongaonkar Thank you for the proposal! I agree we need to simplify plugin management and prioritization. We implemented the way it is as an initial add on and self-contained system as a POC, and now we need to integrate it more tightly across tools, gateways, etc better and more simply. The original intention was to allow users to easily add a plugin or plugins to a set of tools, prompts, gateways, resources etc in a simple fashion and then have a simple way to visualize the plugins across resources,. I like the Spring Cloud gateway example. Happy to collaborate on something like this if you like.

I'd like to see:

1. Tighter integration with the UI and the plugin framework, so that you can add plugins to tools, prompts, resources, servers and gateways.
2. Plugin templates that you can import and modify at each point, so that you can use predefined configurations but modify them if you need to. And be able to save those configurations so that you can import to other tools or servers.

[araujof]

+1

Let's develop this into a proposal that includes the DAG for dependency management, changes to the manifest, etc. This way, we can update the spec and reduce the frequency of breaking changes.