Forem: Rizwanul Islam

From Copilots to Coordination: Why Agentic AI Changes System Design

Rizwanul Islam — Sun, 05 Apr 2026 01:53:59 +0000

Most technical discussions around AI still focus on one question: how much faster can it make existing work?

That is useful, but incomplete.

I (Rizwanul islam Afraim) recently published a paper on SSRN arguing that agentic AI should not be understood only as a productivity tool. It should be understood as a coordination-layer technology.

Paper:
Agentic AI as Coordination Infrastructure Technology: Structural Implications for Firms, Growth, and Economic Divergence
https://ssrn.com/abstract=6236898

The distinction that matters

A lot of teams still think in this progression:

Generative AI = outputs
Copilots = assistance
Agents = better automation

I think that framing is still too narrow.

The deeper shift is this:

When an AI system can decompose a goal, choose tools, execute multi-step actions, route decisions, monitor results, and iterate, it is no longer just helping produce outputs. It is starting to participate in coordination.

That changes how we should think about systems.

Why coordination matters

Most real-world systems are not bottlenecked only by raw task execution.

They are bottlenecked by:

approvals
handoffs
status tracking
supervision
exception routing
documentation
compliance checks
context movement between tools and people

That is why I frame agentic AI as Coordination Infrastructure Technology (CIT).

The argument is that its real structural impact comes from reducing coordination costs across workflows.

What this means for builders

If this framing is right, the important question is not just:
“How do I add AI to this feature?”

It becomes:
“How do I redesign this workflow now that coordination itself can be compressed?”

That leads to different design choices:

fewer human handoff points
more event-driven workflow logic
stronger observability requirements
clearer escalation paths
tighter tool integration
higher importance of permissions and guardrails
more explicit human override layers

Why this is not just a product feature question

Once coordination gets compressed, system architecture starts influencing org architecture.

That means AI is no longer just a UI enhancement or backend helper. It starts affecting:

team shape
process design
management load
internal tooling strategy
capital allocation toward compute, orchestration, and monitoring

That is why I think technical teams should look beyond prompt UX and model quality alone.

The bigger opportunity is in workflow architecture.

Final thought

The most important builders in the next phase of AI may not be the people who simply use AI tools well.

They may be the ones who can redesign systems around reduced coordination cost.

That is the layer I tried to explore in the paper.

Full paper:
https://ssrn.com/abstract=6236898

Check out my site

Rizwanul Islam — Sun, 25 Jan 2026 07:19:38 +0000

It’s been a long time coming, but I finally put my work in one place.

I’ve always preferred building over talking about building, but I realized it was time to create a proper home for my projects and ideas.

Here is the place: https://www.rizwanulafraim.com/

Stop "Vibe Coding." Start Orchestrating: How I Built an Agentic Newsroom (Not a Wrapper)

Rizwanul Islam — Wed, 14 Jan 2026 22:37:04 +0000

By Rizwanul Islam (Afraim) Architect of Intelligent Futures | Founder @ Gaari & The Trail

If you spend five minutes on Tech Twitter in 2026, you'll hear the same phrase repeated like a mantra: "Stop Coding. Start Building."

They call it "Vibe Coding"—the idea that you can prompt-engineer your way to a unicorn without understanding how a database schema works. It is a seductive lie. While vibe coding is great for building toys, it is catastrophic for building Systems.

I don’t build toys. I build architectures reliable enough to hold the weight of thousands of users.

When I architected The Trail (a high-performance news aggregator) and Gaari (Bangladesh’s premium vehicle rental platform), I didn't use AI to write the code for me. I used AI to execute the code I designed.

Here is the difference between a "Wrapper" and an "Orchestrated System"—and why the future belongs to the Architect, not the Prompter.

The "Vibe Coding" Trap "Vibe Coding" relies on probability. You ask an LLM to "build a news app," and it hallucinates a React component that looks pretty but fails under load. It removes the friction of syntax, but it also removes the friction of understanding.

When you build a system like Gaari, which handles:

110+ API Endpoints

Complex multi-service booking flows

Real-time payment gateways (Stripe/Bkash)

You cannot "vibe" your way through race conditions in a database. You need Unshakeable Reliability.

The Shift: Stop treating AI as a "Magic 8-Ball" that writes code. Start treating AI as a "Junior Developer" that requires strict architectural constraints.

Case Study: Architecting "The Trail" as a Swarm Most "AI News Apps" are just wrappers around the OpenAI API. User asks a question -> Bot answers. This is fragile and prone to hallucination.

For The Trail, I didn't want a chatbot. I wanted a digital newsroom. I adopted the Agentic Swarm architecture. Instead of one prompt, the system is orchestrated into specialized agents:

The Planner: Scans the web for trending topics and defines the scope.

The Researcher: Pulls data from verified sources (no hallucinations allowed).

The Writer: Drafts the content based only on the Researcher's data.

The Critic (Crucial): This agent reviews the draft against a quality rubric (SEO, readability, fact-check). If the score is < 8/10, it rejects the draft and forces a rewrite.

The Code vs. The Orchestration
In the "Vibe Coding" world, you just prompt. In the "Orchestrator" world, you build the logic that manages the agents.

TypeScript
// Pseudo-code for The Trail's Orchestration Logic
async function runNewsSwarm(topic) {
const plan = await plannerAgent.createOutline(topic);
const facts = await researcherAgent.gatherData(plan);

let draft = await writerAgent.write(plan, facts);
let review = await criticAgent.review(draft);

// The Orchestration Loop
while (review.score < 8) {
console.log(Quality fail (${review.score}). Rewriting...);
draft = await writerAgent.rewrite(draft, review.feedback);
review = await criticAgent.review(draft);
}

return await publisherAgent.publish(draft);
}
This isn't just "generating text." This is engineering a workflow. It ensures that the final output is high-signal and reliable, distinct from the generic "slop" flooding the internet.

The Stack: Next.js + Supabase (The Reliability Layer) To support this agentic workflow, you need infrastructure that moves as fast as the AI but stays as secure as a bank.

For both Gaari and The Trail, I standardized on the Next.js + Supabase stack.

Why Supabase?
It’s not just because it’s open-source. It’s because of Row Level Security (RLS). When you have AI agents reading and writing to your database, you cannot rely on frontend validation. RLS allows me to define security policies at the database level.

Gaari's Architecture: We handle sensitive user data (bookings, payments). Even if an AI agent goes rogue or a frontend bug appears, the database physically refuses unauthorized queries. That is Unshakeable Reliability.

Why Next.js 14?
For The Trail, we needed a 95/100 Lighthouse score despite having heavy rich-text editors (Tiptap) and real-time analytics. Next.js Server Components allow us to render the heavy news content on the edge, keeping the client bundle tiny.

The "Founder Mode" Mindset There is a viral debate right now about "Founder Mode"—the idea that leaders must know the details.

As the Architect of these systems, I don't delegate the database schema. I don't treat the API as a "black box." I know every one of the 30+ tables in The Trail's schema.

To be a 100x Engineer in 2026, you must pivot:

From: Writing syntax (The AI can do this).

To: Designing Systems (The AI cannot do this).

Conclusion: Build the Engine, Don't Just Paint the Car
The market is crowded with developers who can write a prompt. It is starving for Architects who can build a system.

My work with Gaari and The Trail proves that you don't need a team of 50 to build enterprise-grade software. You need a System Mindset. You need to stop vibing and start orchestrating.

If you are building something that needs to scale, stop looking for "code snippets" and start looking at Architecture Patterns.

I am Rizwanul Islam (Afraim). I architect intelligent futures.

Discussion: Are you using AI to write code, or are you designing systems for AI to execute?

How I Built a Production AI Chatbot (That Actually Handles Complexity)

Rizwanul Islam — Tue, 13 Jan 2026 03:42:03 +0000

The 3 AM Problem
It was 3 AM when I received the notification: another customer had abandoned their booking on Gaari.

The pattern was becoming frustratingly familiar. Users would browse our car rental platform, find a vehicle they liked, and then... stop. Our analytics showed they were getting stuck at the same points—questions about insurance, pickup locations, driver requirements.

The solution seemed obvious: simple chatbot. But most "tutorials" build toy bots. I needed something that could handle:

Context: Remembering previous messages.
Real Data: Querying live car inventory.
Scale: Handling thousands of users without bankrupting me.
That's when I decided to build Gaariwala—an AI chatbot that now handles over 80% of our customer queries without human intervention.

The Architecture
Part 1: The Foundation (Next.js & Vercel AI SDK)
I used the Vercel AI SDK because handling streaming responses manually is a nightmare.

// app/api/chat/route.ts
import { openai } from '@ai-sdk/openai'
import { streamText } from 'ai'
export const runtime = 'edge'
export async function POST(request: Request) {
const { messages } = await request.json()
const result = await streamText({
model: openai('gpt-4-turbo'),
system: You are Gaariwala, a helpful assistant for Gaari...,
messages,
})
return result.toDataStreamResponse()
}
Part 2: Making It Smart (RAG)
The critical piece isn't the AI—it's the data. I built a RAG (Retrieval Augmented Generation) pipeline that checks the user's query against our Supabase database before answering.

If a user asks "Do you have SUVs?", the system:

Detects the intent (vehicle_search).
Queries the vehicles table in Supabase.
Injects the available car list into the System Prompt.
Part 3: Production Optimization
We quickly realized GPT-4 is expensive. I implemented a router:

Simple queries ("What are your hours?") -> GPT-3.5 Turbo
Complex queries ("Compare the sedan vs SUV for a trip to Sylhet") -> GPT-4 Turbo
This reduced our AI costs by 70%.

The Results
80% reduction in support tickets
3x faster response time (instant vs 10+ minutes)
24/7 availability without additional staff
I build systems that scale.

If you enjoyed this architectural deep dive, check out my "Digital HQ" where I showcase real-world production systems like Gaari and The Trail.

🌐 See the Architecture: https://portfolio-rizwanul.vercel.app/