I Made 4 AI Agents Argue With Each Other (Hexagonal Architecture Edition)

Ashish Waghode — Fri, 24 Jul 2026 12:58:58 +0000

Live demo:https://council-of-agents-pi.vercel.app
Source: https://github.com/ashishbot120/Council_of_Agents

The Problem
The problem with asking an AI for architectural advice
Ask a standard LLM "Should we adopt microservices?" and it will hand you a shockingly confident answer. No visible trade-offs, no edge cases considered, and zero insight into why it reached that conclusion.
But that’s not how real engineering decisions are made.
Real architectural choices require debate. I wanted to build something closer to actual team dynamics: multiple distinct AI perspectives arguing their side of the trade-off matrix, followed by a synthesizer that actually weighs the arguments instead of blindly picking a side.

The idea
Council of Agents: four personas Optimist, Critic, Analyst, Devil's Advocate independently answer the same question. A fifth agent, the Chairman, reads all four and synthesizes one final decision.
Real run, question: "Monorepo or multiple repos for a startup team?"

Optimist (85%): monorepo unified tooling, faster onboarding
Critic (87%): multiple repos build complexity at scale
Analyst (80%): monorepo initially, revisit as team grows
Devil's Advocate (85%): multiple repos avoid single point of failure

Chairman's synthesis: adopt a monorepo, but enforce strict modular boundaries and access controls to address the concerns the dissenters raised.
That's more useful than any single agent's answer it absorbed the pushback into a caveat instead of ignoring it.

Why Hexagonal (Ports & Adapters)
The hypothesis: if I design around interfaces instead of concrete SDKs, how cheap does it become to swap providers and survive real-world chaos?

domain/ <- pure business logic, zero framework/SDK imports
entities.py Agent, Proposal, Council, Decision
services/
deliberation_engine.py fires all 4 agents concurrently, tolerates
partial failure
consensus_strategy.py swappable algorithms (Chairman, MajorityVote)

application/
ports/ LLMProviderPort — contracts, not implementations
use_cases/ orchestrates domain + ports

adapters/
outbound/llm/ OpenRouterAdapter, GroqAdapter
inbound/rest/ FastAPI routes

infrastructure/
container.py the ONE file that wires ports to adapters

The rule that makes this actually hexagonal: domain/ and application/ never import a concrete adapter. DeliberationEngine calls llm_provider.get_response(role, query) with no idea which provider is behind it.

Proof it's not just theory: switching the whole system from OpenRouter to Groq took one environment variable — zero lines changed outside container.py. You can even override the provider per-request:

json
POST /council/query
{ "text": "Should we adopt microservices?", "provider": "groq" }

Adding a third provider: ~50 lines
Write OllamaAdapter implementing get_response(role, query) -> Proposal
Register it in container.py
Done — nothing in domain/, application/, or the REST layer gets touched

Four real production incidents

A model got deprecated mid-project. deepseek/deepseek-r1:free vanished between picking it and testing it. Fix: model names live in one dictionary, so swapping is a one-line change, not a hunt.
Two "different" free models shared one rate limit. Different slugs, same underlying host running them concurrently meant they collided on one shared bucket. Fix: pin each agent to a genuinely different upstream provider; model-name diversity ≠ provider diversity.
A reasoning model returned nothing. It spent its whole token budget "thinking" and never wrote an answer json.loads("") blew up. Overcorrecting with a tight token cap caused truncated JSON instead. Fix: budget for both invisible reasoning tokens and the visible answer (max_tokens=1200), and prefer plain instruct models for structured output.
A trailing slash broke CORS in production. CORS_ORIGINS=https://my-app.vercel.app/ browsers send Origin without the trailing slash, and CORSMiddleware does an exact match. One character, total failure, no hint in the code.

None of these took the system down every agent call is independently caught, and the engine returns a decision from whoever did respond. That's _get_proposal_safely(), written on day one because "an external call can fail" was a first-class assumption, not an afterthought.

What this is useful for
A live, non-toy example of Ports & Adapters
A decision-support pattern for tradeoff-heavy questions (architecture, hiring, build-vs-buy)
A resilience case study for anyone building on unreliable third-party APIs

What's next
Postgres adapter for persistence (same port, zero domain changes)
More consensus strategies (weighted voting, rebuttal rounds)
Streaming individual agent responses
A local Ollama adapter for a fully free path
An eval harness comparing consensus strategies over time

Contributions welcome

This is very much a living project, not a finished one. If you want to add a consensus strategy, wire up a new provider adapter, or just poke holes in the architecture — PRs and issues are welcome. Good first ones to try: a local Ollama adapter, a Postgres decision repository, or a new persona.

Adaptive Traffic Optimization

Ashish Waghode — Sun, 12 Jul 2026 08:53:20 +0000

Problem Statement: Standard fixed-time traffic controllers operate on rigid, pre-programmed cycles without real-time situational awareness, leading to inefficient green-time allocation and increased congestion at unbalanced intersections.

Project Objective: This project develops an adaptive traffic signal control system that utilizes real-time vehicle counts per approach. By leveraging a dynamic agent [or reinforcement learning agent, if applicable], the system optimizes phase sequencing to maximize throughput and minimize cumulative commuter delay.

Solution:I developed a closed-loop, adaptive traffic management system that replaces static signal cycles with real-time, data-driven decisions through four key components:

Real-Time Perception: Deployed a YOLOv8 and OpenCV pipeline across four directional video feeds to detect, classify, and count queued vehicles within defined regions of interest.

Intelligent Decision-Making: Implemented and compared two Reinforcement Learning agents a baseline Tabular Q-Learning model and a PyTorch based Deep Q-Network (DQN) trained on a custom reward function designed to minimize cumulative intersection wait times.

Visual Validation: Built a custom Pygame environment to simulate intersection physics and signal states, enabling real-time visual auditing of the RL agents' behaviors.

Centralized Control Plane: Wrapped the architecture in a FastAPI web application featuring asynchronous MJPEG streams of the detection feeds, live telemetry endpoints, and a frontend dashboard to monitor vehicle metrics and training performance graphs.

Future Improvements:Support more intersection types generalize the fixed 4-direction setup (N/S/E/W) into a configurable N-way system, so the same agent can handle 3-way junctions, 6-way intersections, or roundabouts just by changing a config instead of the code.

Phase-based signals instead of picking one direction at a time, group compatible directions into phases (e.g., opposing traffic together) like real signal controllers do.

Multi-intersection coordination extend from a single junction to a network of connected signals (multi-agent RL) for corridor-level "green wave" optimization.

Richer inputs factor in queue trends over time, pedestrian/cyclist detection, time-of-day patterns, and emergency vehicle preemption.

Better benchmarking compare fixed-timer vs. Q-learning vs. DQN on wait time and throughput to actually quantify the improvement.

Realistic simulation swap the pygame simulator for SUMO to test against real world traffic patterns before live deployment.

This is a proof of concept, so there's plenty of room to build on whether it's extending the RL agent, adding support for more intersection types, or improving the simulation. Check out the repo, open an issue, or send a PR: Traffic-Optimize on GitHub
(https://github.com/ashishbot120/Traffic-Optimize).

DEV Community: Ashish Waghode

I Made 4 AI Agents Argue With Each Other (Hexagonal Architecture Edition)

Adaptive Traffic Optimization