DEV Community

CommerceFrame
CommerceFrame

Posted on Originally published at opensourceaiagentframework.com

When an agent framework stops being enough

Most teams building with AI agents start with a framework. LangGraph, CrewAI, AutoGen and OpenHands give you primitives: nodes, edges, tools, hand-offs. You add them to an application, write the orchestration, and decide how each agent runs. That is the right call while the product you are building is the application itself and your engineers want to control every step.

The wall shows up later, when the agents start doing work the company depends on. A framework is a library. It does not give each run its own isolated machine, its own branch, a change request, or an audit trail. Durable state, shared memory and human review are things your team assembles around it. Nothing enforces them, so they drift.

That gap is where the framework-versus-platform question actually lives.

What a framework gives you

  • Composition primitives for multi-step agent runs.
  • A programming model your engineers already use.
  • Maximum control over the runtime, as long as you build it.

LangGraph models agents as a graph of stateful nodes (LangGraph). CrewAI models them as a crew of role-playing agents and tasks (CrewAI). AutoGen and OpenHands sit in the same family: libraries and harnesses your code drives. The framework decides how an agent thinks. Your team still decides where it runs, what it may touch, and how its output gets reviewed.

What a platform adds

A platform runs and governs the agents instead of asking you to orchestrate them. That is the layer Kortix is built for. Kortix is the open-source AI Operating System: agents, skills, company memory and every connector live in one git repo you own. Each session runs on its own cloud computer and its own branch, and the work reaches main through a change request a person reviews first. You configure the agents in files; the platform carries the runtime, the isolation, the review and the audit.

The distinction matters for three reasons:

  1. Where the run happens. A framework leaves the environment to you. Kortix gives every session an isolated sandbox on its own branch (Kortix docs).
  2. What a person reviews. A change request is a diff a person approves or rejects. In a framework that is wiring you write.
  3. What the company owns. The configuration, the memory and the connectors are files in a repo you control, not settings in someone else's database.

How to decide

Pick a framework when the application is the product and your engineers want to assemble the runtime themselves. Pick the platform when the agents do work the wider company reads, approves or audits, and you want that review to be part of the system rather than a script someone maintains.

The two are not exclusive. A team can run its own graph inside a Kortix session; the framework builds a piece, the platform runs it and lands the result for review. The line that decides it is not capability, it is who owns the loop around the agent: the run, the isolation, the approval, the audit. If that loop is your code, a framework is enough. If you want it to be the platform, start from one you can own.

Kortix is open source. You can self-host it for free or run it on Kortix Cloud, on any model provider with your own keys. The framework-or-platform breakdown, with the four frameworks compared, is here: Framework or platform?.

Top comments (0)