# Building an AI System Taught Me It’s Not About the Model

But here’s the uncomfortable truth:

**Using an LLM API is not impressive anymore.**

Anyone can do it.  
And honestly, most people are doing the same thing.

Call an API → write a prompt → get a response.

That’s not system building. That’s just usage.

* * *

## The Realization

At some point, it hit me:

> There’s nothing creative about just using an LLM API.

Unless you’re training or fine-tuning models yourself, you’re operating at the same level as everyone else.

The real differentiation is not the model.

It’s everything around it.

*   How you structure the system
    
*   How you control execution
    
*   How you manage data flow
    
*   How you handle reliability, cost, and scale
    

That’s where actual engineering begins.

* * *

## The Problem I Wanted to Solve

I started with a simple but frustrating problem:

**Getting reliable, unbiased, and well-researched news is hard.**

Not just headlines—but actual understanding.

Things get messy quickly:

*   News is scattered across sources
    
*   Bias is everywhere
    
*   Verifying authenticity takes effort
    
*   Exploring a topic deeply requires jumping across multiple links
    

Now try answering something like:

> “What are the latest global developments in AI regulation, and what do they actually mean?”

This is not a single search.  
This is a **multi-step research process**.

You need to:

*   Discover relevant articles
    
*   Extract sources and links
    
*   Read and validate content
    
*   Follow deeper references
    
*   Synthesize everything into a coherent answer
    

This is where naive “LLM + prompt” approaches fail.

* * *

## The Shift in Thinking

I stopped thinking:

> “How do I get a better answer from the model?”

And started thinking:

> “How do I build a system that can *arrive* at a better answer?”

That’s a completely different problem.

* * *

## The System I’m Building

Instead of a single AI component, I broke the system into layers.

### 🧠 [Agent (Reasoning Layer)](https://tuhindutta.github.io/news-agent/)

Handles:

*   Decision making
    
*   Multi-step execution
    
*   When to fetch data
    
*   How to synthesize results
    

* * *

### ⚙️ [MCP Server (Execution Layer)](https://tuhindutta.github.io/news-agent-mcp-server/)

Handles:

*   Fetching latest news
    
*   Scraping websites
    
*   Returning structured and unstructured data
    

* * *

### 🚪 Gateway (Control Layer — in progress)

*Under development...*

Handles:

*   Authentication (JWT)
    
*   Rate limiting
    
*   User access control
    
*   System exposure
    

* * *

### 🗄️ State Layer

*   PostgreSQL for conversation and session tracking
    

* * *

## Process Flow

![](https://cdn.hashnode.com/uploads/covers/681f9f18677f0d877517d5ae/9dce89a5-e8ba-4dd8-b531-ca08d64c487b.png align="center")

* * *

## How It Fits Together

At a high level:

*   The **agent thinks**
    
*   The **MCP server executes**
    
*   The **gateway controls**
    
*   The **database remembers**
    

* * *

## Why This Separation Matters

This is where things started to click.

Once responsibilities are separated:

*   You can scale components independently
    
*   You can secure the system properly
    
*   You can control cost and abuse
    
*   You can evolve each part without breaking everything
    

Most “AI projects” skip this entirely.

That’s why they don’t go beyond demos.

* * *

## Why I’m Building the Gateway in Go

I could have used Python again. But, I didn’t.

Because this layer is different.

This is not about AI.  
This is about **control and infrastructure**.

Go fits better here:

*   Lightweight and fast
    
*   Strong concurrency model
    
*   Ideal for API gateways and control services
    

This was less about learning a new language, and more about **choosing the right tool for the role**.

* * *

## What This Really Is

This is not just a “news agent”.

It’s evolving into:

> **A modular LLM system for controlled, iterative research workflows**

Where:

*   reasoning is separated from execution
    
*   execution is separated from control
    
*   and everything is designed to scale
    

* * *

## What I Learned

A few things became very clear during this process:

*   LLMs are the easiest part of the system
    
*   System design is where the real complexity lies
    
*   Control and safety are not optional
    
*   Separation of concerns is not over-engineering—it’s necessary
    

* * *

## What’s Next

*   Completing the Go-based gateway
    
*   Integrating all components
    
*   Deploying the system on AWS (likely ECS)
    
*   Building a UI layer on top
    

* * *

This started as an AI project.

It turned into a system design exercise.

And honestly, that’s where the real learning happened.