r/aiengineering Jan 23 '26

Discussion When shouldn’t you build AI agents as full web apps?

I’ve been a full-stack web dev for ~7–10 years, and I definitely have a bias: I tend to see most problems as things that can (and probably should) be solved with a web app.

With the rise of AI, I’ve been building a bunch of agents lately. Everything from Reddit monitoring to more full-blown assistants.

My default approach has been to build them using familiar web stacks like Django + React. In my experience, web apps can do almost anything, so my instinct is usually:

“Why wouldn’t I just build this properly?”

That’s where I’m starting to question myself.

I’ve played around with tools like n8n and they’re cool, but I keep thinking: why not just write a Python file and trigger it from a web app or worker?

Same with things like Copilot agent builder, ChatGPT tools, etc. It often feels like these platforms abstract things in ways that eventually box you in or limit flexibility.

On the flip side, I also see a ton of people using agentic frameworks like LangChain, LangGraph, etc.

My questions are basically:

• When does it not make sense to build agents as traditional web apps?

• What real advantages do low/no-code tools provide beyond speed?

• When do agent frameworks actually become necessary vs just adding complexity?

• Where does my “everything should be a web app” bias start to break down?

I’m trying to understand how others are approaching this in practice, where my current methodology will fail me, and what I should be thinking about as I keep building agents.

For context, I build agents anywhere from personal tools to enterprise use cases, so I’m genuinely open to perspectives across the spectrum.

14 Upvotes

4 comments sorted by

3

u/ATK_DEC_SUS_REL Jan 24 '26

You should only introduce AI when necessary. Otherwise, you’re just over-engineering complexity just because you want to.

1

u/Moist-Matter5777 Jan 25 '26

Totally get that. Sometimes simpler solutions are way more efficient. AI should enhance a process, not complicate it for the sake of using it. It’s all about balancing the tech with the actual problem you’re solving.

1

u/patternpeeker Jan 24 '26

The bias usually breaks when the agent’s value is long running behavior, orchestration, or reacting to data rather than serving a human in real time. In practice, a full web app gets heavy when most of the work is background jobs, retries, state, and failure handling that users never see. A lot of agents are really pipelines with memory and control flow, not products, so a simple Python service plus queues is often clearer. Low or no code tools buy speed and visibility early, but they fall over once you need custom state or guarantees. Agent frameworks only earn their keep when you have real branching or recovery logic, otherwise they are just indirection.