The Abstraction Boundary of an AI Platform: Who Ultimately Bears the Complexity?
I have recently been using Factory.
If Claude Code is something like a highly capable Coding Agent, Factory is attempting something larger: organizing software development as a production system driven by Agents. It does not merely help engineers write code, but tries to cover planning, implementation, testing, and review. For larger tasks, Missions breaks down the work, coordinates Workers, and assigns Validators to verify the results at the end of each milestone.
Behind this design lies a question: Is the platform absorbing complexity on behalf of users, or replacing the old complexity with a new set of concepts they must learn?
What Kind of Barrier Does Dify Lower?
When I first encountered Dify, much of it felt intuitive. Drag in a few nodes, connect a model and a knowledge base, add the tools you need, and you can quickly build an AI application. Compared with writing everything from scratch, the barrier to entry is indeed much lower.
But in an enterprise environment, another layer of complexity gradually emerges.
Users need to understand Workflows, Agents, retrieval-augmented generation (RAG), variables, tool calls, knowledge bases, and differences among models. A private deployment also requires dealing with Kubernetes, databases, networking, permissions, version upgrades, plugins, and licensing.
Dify lowers the initial barrier to building AI applications, but it does not make the complexity of running them in real environments disappear. It simply redistributes that complexity: the platform absorbs some of it, while the rest becomes knowledge required to use and operate Dify.
That is not necessarily a product design failure. Enterprise software inherently has to address permissions, security, reliability, and integration; no platform can make these concerns vanish. The question worth watching is which kinds of complexity users must understand, and which the product will continue to absorb as it matures.
Looking at Factory Through the Same Lens
Factory is far simpler than building an Agent System from scratch. Missions already organizes planning, execution, and validation into a complete path, and the system provides built-in Workers and Explorer. By default, a Subagent can inherit the main session’s model and Reasoning Effort, or use a model chosen according to task complexity. For simple tasks, the official documentation recommends using a regular session directly rather than starting a Mission.
These defaults and built-in roles show that Factory is not leaving all orchestration to the user. It is also trying to provide a path that works out of the box for different kinds of tasks.
As they continue using it, however, users still encounter a new set of choices:
Which model is best suited to the Orchestrator, and which to the Worker?
Should the Validator use a more capable model or a less expensive one?
How high should Reasoning Effort be set?
Which tasks are worth delegating to a Subagent, and which are better completed continuously by a single Agent?
For people who enjoy studying Agent Systems, these are interesting questions, and the additional control may even be part of the product’s appeal. But the problem most users actually want to solve may be no more than “help me fix this bug” or “get this feature into production faster.” They care about delivery; they do not necessarily want to become experts in models and orchestration first.
Becoming a Platform Does Not Mean Becoming Simple
A platform’s natural impulse is to expose its capabilities. Only by allowing users to configure nodes, models, Workers, and validation methods can it cover enough use cases and serve its earliest professional users.
So early complexity is not something to fear. Kubernetes, Terraform, and Datadog were not easy to use at first either. A professional tool must first make the capability work; only then can it begin absorbing complexity in response to real-world use.
A truly excellent platform must eventually take back the complexity it exposes to users today.
Models that users must currently choose themselves could later be routed automatically by the system according to the task and its risks. The system could also decide whether a task should be divided and how Workers should be organized. The same applies to Validation: its rigor should depend on the scope of the change and the cost of failure, rather than requiring users to design it from scratch every time.
Factory can already reduce some decisions through built-in Workers, model inheritance, and complexity tiers. Missions also organizes multi-Agent collaboration that users would otherwise have to assemble manually. The question is not whether it has begun absorbing complexity, but how far down this path it can ultimately go.
Let Users Describe Constraints, Not Implementation
A mature AI product should not require users to understand models ever more deeply. It should help them describe their problems with ever greater precision.
For example, users should need to say only:
This is a bug in production.
Prioritize quality.
Finish within two hours.
Cost is not the first priority.
Whether to split the work among Subagents, how many Workers to start, which model to select, when to validate, and whether to escalate to a stronger model after a failure could all be decided by the system based on those constraints.
What users truly care about has not changed much: whether the result is good, whether it is fast, and whether it is expensive. Which model is used underneath, how many Agents are involved, and how they are orchestrated are all implementation details. If users must first understand those details before they can reliably obtain results, the product’s abstraction still has room to evolve.
How many concepts unique to this product must someone learn before they can use it?
If users are learning about their own work—software engineering, sales, customer service, or law—that knowledge can directly improve their judgment. But if they spend a great deal of time understanding Nodes, Workers, Missions, Validators, Routers, and Context Strategies, the product is still leaving much of its internal complexity with them.
Configuration does not need to disappear entirely. Professional users need ways to debug, and enterprises need to control costs, security, and model compliance. A good abstraction should give most people reliable results without requiring configuration, while preserving the ability to intervene when necessary.
An AI Platform should be judged by how much complexity it can ultimately absorb for users, not merely by how much capability it exposes.
What I find interesting about Factory is precisely that this question remains far from settled.