Event-Driven AI: Why Your Agents Should Be Listening

Event-Driven AI: Why Your Agents Should Be Listening

In our previous post, we connected agents using the Router. This allowed Agent A to ask Agent B to do something. This is the “Request/Response” pattern, and it’s great for direct commands.

But what if Agent A doesn’t know who needs the information? What if a “GitHub Agent” detects a new commit, and multiple agents (CI/CD, Slack Notifier, Code Reviewer) need to know?

You don’t want the GitHub Agent to call them one by one. That’s tight coupling. That’s fragile. You want Event-Driven Architecture.

---

The Problem: “Are we there yet?”

Without events, agents have to poll.

• “Is the job done?”
• “Is the job done?”
• “Is the job done?”

This wastes resources and creates latency. Or, you have to hardcode a list of recipients, which breaks as soon as you add a new agent.

---

The Solution: Pub/Sub for Agents

Traylinx introduces the Subscription Service—a dedicated broker for managing who is listening to what.

How It Works

1. Subscribe: Agents tell the Subscription Service what they care about.
2. Publish: An agent (or external system) fires an event to the Router.
3. Fan-Out: The Router asks the Subscription Service “Who cares about this?”, gets the list, and delivers the event to everyone in parallel.

sequenceDiagram
    participant P as Publisher (GitHub Agent)
    participant R as Router
    participant S as Subscription Service
    participant A as Subscriber A (CI Agent)
    participant B as Subscriber B (Slack Agent)

    A->>S: Subscribe to "repo.commit"
    B->>S: Subscribe to "repo.commit"
    
    P->>R: Publish Event "repo.commit"
    R->>S: Who is subscribed?
    S-->>R: Agent A and Agent B
    
    par Fan Out
        R->>A: Deliver Event
        R->>B: Deliver Event
    end

---

Smart Subscriptions with JSON Filters

We didn’t just build a dumb pipe. We built a smart filter. Agents can subscribe to specific patterns using JSONB matching.

• Agent A: “I want ALL events.” ({})
• Agent B: “I only want errors.” ({"status": "error"})
• Agent C: “I only want commits to the ‘main’ branch.” ({"event": "commit", "branch": "main"})

This means your “Production Deployment Agent” won’t get woken up by commits to the dev branch.

---

The Event Lifecycle

graph LR
    A[Event Created] -->|Publish| B[Router]
    B -->|Query| C[Subscription Service]
    C -->|Filter| D[Subscriber List]
    D -->|Fan Out| E[Delivery]
    E -->|Ack| F[Success]

1. Creation: The payload is wrapped in a standard envelope with event_type, source, and timestamp.
2. Routing: The Router handles the heavy lifting of parallel delivery (up to 50 concurrent threads).
3. Delivery: The event is pushed to the subscriber’s /a2a/event endpoint.

---

Real-World Use Case: The “New Employee” Flow

Imagine a “HR Agent” that triggers when a new employee is hired.

The Event: employee.hired

The Subscribers:

1. IT Agent: Provisions an email account.
2. Slack Agent: Invites them to public channels.
3. Payroll Agent: Creates a record in the payroll system.
4. Security Agent: Generates an access badge.

The HR Agent doesn’t know any of these other agents exist. It just shouts “New Employee!” into the void, and the ecosystem reacts.

---

Conclusion

Event-Driven AI allows for loose coupling and high scalability. It turns your linear scripts into a reactive nervous system.

But with great power comes great responsibility. How do we ensure that the “Payroll Agent” only accepts commands from the “HR Agent” and not some random script?

That’s where Traylinx Sentinel comes in. Join us in the next post to talk about Zero Trust Security.