What is an Agentic App? The Next Evolution of Software

After building OnSpace.ai from the ground up, I've come to believe something that might sound bold: within a year, most new apps will be agentic apps. You're already seeing it—teams everywhere are rebuilding traditional applications with agentic architectures. The shift is happening fast.

But here's the thing: when I first started building my own agentic app, I was completely confused about what that even meant. And I'm not alone. The term "agentic app" gets thrown around constantly, but people have wildly different ideas about what it actually is:

• Some think that building a workflow in n8n with an LLM call somewhere makes it agentic
• Others believe adding a chatbot interface to their app = instant agentic app
• Then there are the purists who insist nothing counts unless it's fully autonomous, making its own decisions with zero human guidance

I'm going to walk you through the three stages I went through building OnSpace.ai, from rigid workflows to full autonomy. At each stage, I'll show you what you gain, what you give up, and when each approach makes sense. By the end, you'll have a clear framework for thinking about agentic apps—and you'll know exactly which approach fits your use case.

The Autonomy Spectrum

Let me show you what this looks like in practice.

A Real Example: Building OnSpace.ai

To make this more concrete, let me share my own journey building OnSpace.ai—a coding agent that evolved through all three stages of the agentic spectrum.

Stage 1: The Workflow-Based Approach

Early on, I was using LLMs to help with coding problems. It worked, but the process was painfully manual and repetitive. Every single time I wanted to modify code, I had to:

1. Gather my existing codebase and feed it to the LLM as context
2. Explain what compilation errors I was hitting
3. Carefully decide whether to ask for full file rewrites or partial changes
4. If partial changes, manually locate where in my code to apply them
5. Deal with hallucinations—when the LLM's output still had issues, I'd start this whole dance over again

After doing this hundreds of times, I realized: this is just a workflow. A tedious, repetitive workflow that a computer should handle.

So I built one. I wrote code that would:

• Automatically gather context using various tools
• Send it to the LLM with the right prompts
• Parse the LLM's output and merge it with my existing code
• Run the compiler for syntax checking and basic unit tests
• If errors were found, loop back and try again with the error messages as new context

This workflow changed everything. It was stable, predictable, and dramatically improved my productivity. I shared it with fellow developers, and they had the same reaction—it just worked.

Stage 2: The Hybrid Approach

But as OnSpace.ai grew more capable, my single workflow became painfully complex. I kept running into situations it couldn't handle:

• Sometimes my instructions were vague—I didn't want the system to immediately start coding. I wanted to discuss requirements first, clarify what I actually needed.
• When working with backend storage, I needed to provide my Supabase API key and teach the LLM how to use Supabase's API correctly—not something a fixed workflow could adapt to.
• File handling got complicated. When I uploaded images, docs, PDFs, or Excel files, the system needed different tools for each type. Plus, I had to manage token limits carefully to avoid attachments consuming the entire context window.
• For partial code changes, I needed to ensure the LLM wouldn't accidentally break other parts of the codebase.
• And there were many more edge cases like these.

The solution? I introduced decision nodes. Instead of one rigid workflow, I built multiple workflows for different scenarios. Then I let the LLM decide which workflow to use based on the context—what I was asking for, what files I uploaded, what state the project was in.

This was the hybrid approach: predetermined workflows as building blocks, but dynamic decision-making about which blocks to use and when. The LLM became more than just a smart function—it became a coordinator, choosing the right strategy for each situation.

Stage 3: The Agent-Based Approach

Here's the thing about the hybrid approach: as you add more and more decision logic and execution paths, you start asking yourself—why not just let the LLM handle all of it?

Before going agent-based, I studied all the successful examples out there. I was captivated by these impressive agents and wanted to try building one myself—like many of you probably were.

At first, the agent mode brought wonderful surprises. The LLM would solve problems in creative ways I hadn't anticipated. The results genuinely caught me off guard.

But then something shifted. The system started to feel… uncontrolled. It developed its own way of thinking. For the first time, I felt uneasy about the unpredictability. I couldn't predict what it would do after each instruction.

So I spent countless hours working on controllability. I had to:

• Carefully select relevant background knowledge from my knowledge base for each input
• Prepare extensive best practices as examples for the LLM to learn from
• Extract key information from past conversations to build memory
• Switch between different LLMs based on the scenario to maximize effectiveness
• And much more.

OnSpace.ai was no longer just a tool. It had become something I was deeply invested in.

So, What Actually Makes an App "Agentic"?

After going through these three stages, here's my definition:

The spectrum from workflow-based to agent-based is really about how much autonomy you give the system in each of these areas.

The Future is Agentic

I've come to believe that as LLMs continue improving, we'll see a fundamental shift in how we build software. The traditional paradigm of rigid, workflow-based applications will increasingly give way to hybrid and agent-based approaches. More and more apps will become agentic apps.

This shift is already happening. The question isn't whether to build agentic apps, but how to build them well.

Building OnSpace.ai taught me countless lessons—about prompt engineering, memory systems, tool orchestration, error handling, and keeping autonomous systems under control. The kind of lessons you only learn by actually building and using an agent in production, day after day.

The interesting part? These lessons are now embedded in OnSpace.ai itself. It learns from the experience of being built. Which means when you use it to build your next project, you're leveraging all those hard-won insights.