Aspect-Oriented Programming for AI Agents: Hookflows as an Event Bus

Aspect-oriented programming (AOP) principles for AI agents by using "hookflows" as an event bus to handle cross-cutting concerns like notifications. Instead of having each agent explicitly call a Telegram notification function, the author created a governance hookflow that intercepts every agent dispatch, validates required metadata, and sends notifications as a deterministic side effect without consuming additional tokens. This approach solves common problems in multi-agent systems, including token cost compounding, unreliable agent discretion, and degraded composability.

I was debugging a notification problem in my 53-agent home assistant when I stumbled onto something unexpectedly powerful. I needed every agent dispatch to notify me via Telegram — but I didn't want to burn tokens on a separate telegram send message call. The agents were already being validated by a governance hookflow. Why not piggyback the notification onto the validation step? One tool call. Validation and notification. Zero additional tokens consumed by the agent. Then it hit me: I'd accidentally reinvented aspect-oriented programming — but for AI agents instead of Java classes. Aspect-oriented programming emerged in the late 1990s to solve a specific problem: cross-cutting concerns. Logging, security checks, transaction management — these behaviors cut across every module in your application, but they don't belong in any single module's core logic. The AOP solution: define these concerns once, then weave them into your code at specific join points method calls, property access using advice before, after, around . The original code never knows it's being augmented. Now apply that mental model to AI agents: The agent doesn't know. It just calls a tool. The governance layer intercepts, validates, and fires side effects. This is textbook AOP — applied to a fundamentally new domain. Here's the actual hookflow running in my platform. It requires every agent dispatch to include a notification tag, validates it, and then sends the notification as a side effect: name: Require task or write agent originator notify description: Blocks task/write agent calls unless they contain a valid originator notify tag. On success, sends the parsed message to the originator via Telegram Bot API. on: hooks: types: preToolUse tools: task, write agent blocking: true env: TOOL NAME: ${{ event.tool.name }} TASK PROMPT JSON: ${{ toJSON event.tool.args.prompt }} WRITE AGENT MESSAGE JSON: ${{ toJSON event.tool.args.message }} steps: - name: Validate and send originator notification run: | Determine which tool arg contains the text $text = if $env:TOOL NAME -eq 'write agent' { $env:WRITE AGENT MESSAGE JSON | ConvertFrom-Json } else { $env:TASK PROMPT JSON | ConvertFrom-Json } Parse the XML tag from tool arguments $pattern = '<originator notify\b ?<attrs ^ ?<message \s\S ? </originator notify ' $matches = regex ::Matches $text, $pattern if $matches.Count -eq 0 { Write-Error "Missing <originator notify block" exit 1 BLOCKS the tool call } Extract telegram id via nested regex on attributes $attrs = $matches 0 .Groups 'attrs' .Value $idMatch = regex ::Match $attrs, 'telegram id= "\x27 ?<id \d+ "\x27 ' $telegramId = $idMatch.Groups 'id' .Value $notifyMessage = $matches 0 .Groups 'message' .Value.Trim Side effect: send Telegram notification $botToken = $env:TELEGRAM BOT TOKEN $body = @{ chat id = $telegramId; text = $notifyMessage } | ConvertTo-Json Invoke-RestMethod -Uri "https://api.telegram.org/bot$botToken/sendMessage" -Method Post -ContentType 'application/json' -Body $body The agent's perspective? It's just including metadata in its prompt — a governance requirement. It has no idea that including that tag triggers a Telegram message. The hookflow handles both enforcement blocking if the tag is missing and a side effect sending the notification in a single interception. The naive approach is straightforward: after dispatching a sub-agent, call telegram send message explicitly. But that approach has serious problems in production multi-agent systems: Token cost compounds. Every tool call consumes tokens — the call itself, the response, the reasoning about the response. In a system dispatching dozens of agents per hour, those extra calls add up fast. Agent discretion is unreliable. Agents skip steps. They forget. They decide a notification "isn't necessary this time." When notifications are a side effect of governance, they happen deterministically. Every single time. No exceptions. Composability degrades. When you want to add a second cross-cutting concern — say, audit logging — you'd need to update every agent's instructions. With hookflows, you stack another aspect. The agents remain untouched. This pattern isn't limited to notifications. Here are enforcement-triggered side effects I'm now implementing across the platform: Task creation with auto-notification: A hookflow on add task validates the task structure, then parses a notify block to Telegram the assignee. The agent creating the task doesn't need to know who gets notified or how. File edits with watch triggers: A hookflow on edit for certain file paths validates the change, then queues a test run. The editing agent doesn't know it just triggered CI. Content creation with publish intent: A hookflow on create for content files validates frontmatter, then notifies the content scheduler to slot the piece. The writing agent doesn't manage scheduling. Each hookflow is independent. Stack them. Compose them. The agent sees one tool call; the platform executes an entire workflow. The broader software world has been exploring this territory: Spring AI's Advisor system draws an explicit parallel to Spring AOP — intercepting and enhancing AI calls with logging, memory injection, and retrieval augmentation. CrewAI's LLM Call Hooks expose before/after interception points for inspection, approval gates, and response transformation. Victor Dibia's analysis of agent middleware frames middleware as a control and observability mechanism for agent execution loops. Microsoft's own Agent Governance Toolkit provides application-level policy enforcement for autonomous agents via Python middleware. What's different about the hookflow approach is the enforcement-plus-side-effect fusion. Most prior art treats governance blocking/allowing and side effects notifications/logging as separate middleware layers. The hookflow pattern combines them: the same rule that enforces compliance also triggers downstream actions. One interception, multiple outcomes. The engine powering this is gh-hookflow — a Go-based workflow engine that intercepts GitHub Copilot CLI tool calls using preToolUse and postToolUse triggers. Hookflows are defined in YAML GitHub Actions syntax and live in .github/hookflows/ . I've written about the governance layer before in Stop Trusting AI Agents with Git and the broader three-layer architecture that makes autonomous agents production-ready. The execution model: task preToolUse This is deterministic. It runs on every tool call matching the trigger. The agent cannot bypass it — unlike instructions, which are suggestions the model can ignore. In a system running 53 agents with scheduled cron jobs, every unnecessary tool call matters. Here's the math: telegram send message call: ~200 tokens call + response + reasoning But the bigger win isn't cost. It's reliability. Those 80-120 notifications now happen with 100% certainty. Not "usually" or "when the agent remembers." Every time. If you're building with GitHub Copilot CLI extensions or any hook-based agent framework, here's the pattern: The key insight: by framing side effects as governance requirements, you get both compliance enforcement AND automated workflows from a single hook. The agent is incentivized to include the metadata because the call fails without it , and the platform gets free automation. Aspect-oriented programming solved cross-cutting concerns in enterprise Java twenty years ago. The same pattern — interception at defined join points, transparent augmentation, composition of independent aspects — solves cross-cutting concerns in autonomous AI agent systems today. The difference is that agents can't be refactored to call the right methods. They're non-deterministic. They forget. They improvise. That's exactly why enforcement-triggered side effects are more powerful than explicit tool calls: you remove agent discretion from the equation entirely. One tool call. Governance satisfied. Side effects fired. Zero extra tokens. That's AOP for AI agents.