When I started building AI into Polyform, I assumed the hard part would be making the model smarter.
It wasn't.
The hard part was building the right system around the model: how it gets context, how it interacts with our product, how it does long-running work, and how any of that becomes an experience a normal person would actually want to use.
We went through five versions of that system. Each one solved the previous version's biggest problem and exposed a new one underneath it.
The journey taught me something I now believe strongly: the best AI product is not one giant agent trying to do everything. It is a fast conversational agent that knows when to hand substantial work to a different kind of agent.
At Polyform, that became Polly with DeepWork.
Version 1: put a chatbot in the product
The first version was the obvious one: give the user a standard ChatGPT-like conversation.
For simple questions, it was great. The user asked something, the AI responded, and the whole interaction felt immediate and magical.
Then we asked it to do real work.
Anything multi-step exposed the limits quickly. We had to push enormous amounts of context into the conversation. The model had to choose from a growing collection of custom tools. Every extra step created another place for the chain to break. Costs climbed, latency climbed, and the quality still felt brittle.
It could answer. It could sometimes act. But it could not reliably investigate an unfamiliar situation, adapt its approach, and keep working until the result was actually useful.
The failure was not just that the model made mistakes. The architecture itself was inflexible. We were trying to anticipate every possible thing a user might ask and turn it into a purpose-built tool call.
Real work is not that tidy.
Version 2: let the agent use a computer
My thinking changed when I started using Codex.
Codex felt dramatically more flexible than the agents we had been building. I could give it a messy goal and a directory full of context. It could inspect files, write Python, run commands, change its plan, and use the filesystem as working memory. I did not have to predict every step in advance.
Code is a universal adapter.
If an agent can inspect data, write a small program, and use ordinary tools, it does not need a bespoke API call for every variation of a task. It can compose its own solution.
This is part of what makes products such as Codex and Claude Code feel so capable. Codex runs substantial tasks in their own environments, where the agent can read and edit files and run commands; it is guided by repository instructions rather than one enormous prompt. OpenAI's description of Codex captures the shift well.
But borrowing a coding agent did not automatically make our product agent good.
When the only way into your application is a pile of narrow APIs, even a capable agent spends too much of its intelligence fighting the interface. The agent may be flexible, but the product underneath it is not legible.
Version 3: make the entire platform CLI-first
So we changed the platform.
We made Polyform CLI-first: everything a user can do in the interface should also be possible through the command line.
That decision did much more than give us a terminal client. It created an agent-readable version of the product.
A good CLI has built-in discoverability. The agent can ask for help, inspect available commands, learn the shape of an operation, try something, read the error, and adjust. Authentication is consistent. Commands compose. The same interface can be used by a person, a script, or a coding agent.
Instead of building hundreds of special tools that approximated what our application could do, we gave the agent the same capabilities the user already had.
The improvement in reliability was immediate. The agent produced higher-quality answers more consistently because it could investigate the system directly. When it encountered something unexpected, it had room to maneuver.
If you want an agent to operate your product well, give it a complete, discoverable interface, not a bag of disconnected actions.
Version 4: wrap the coding agent in a product experience
The CLI-first agent was powerful, but it was not yet a product experience.
Users did not want to read raw commands and terminal output. So we built an interface around the agent and a parser that translated what it was doing into language a user could understand.
This was the most capable agent we had built. It could open a workspace, use our CLI, inspect data, write code, and work through complicated questions. It could do almost anything a user could do in Polyform and quite a few things a user would never want to do manually.
It was also insanely expensive and slow.
We were spinning up a whole computer and a full coding agent for interactions that might have needed only a sentence. Even when the result was excellent, waiting for that machinery made the product feel unnatural. The architecture treated every message like a research project.
Capability was no longer the problem. Proportionality was.
The file-first breakthrough
The biggest cost reduction came from changing how the CLI returned data.
Originally, a command would fetch an object and pour the entire result back into the model's context. That is the intuitive pattern and, for large data, a terrible one. The model pays attention to all of it whether or not all of it matters.
We changed the CLI to be data-file-first. A command could now say, in effect: I fetched the object. It is in this file.
The agent could search the file, inspect a small range, write a script over it, or load only the fragments it needed. The filesystem became a layer of cheap external memory instead of forcing the model's context window to become the database.
That produced better results with fewer model calls and dramatically fewer tokens. The agent stopped repeatedly carrying around data it was not using.
Move data to the agent's environment, not through the agent's context. Give the model a map to the data and tools to inspect it.
The file-first architecture made the powerful agent much cheaper. It did not make it feel fast.
Version 5: Polly with DeepWork
The final breakthrough came when we stopped trying to force one agent to be both responsive and exhaustive.
Those are different jobs.
Today, Polyform has two complementary layers.
Polly is the conversational layer. Polly understands Polyform, has just enough context, and can use a focused set of tools for common actions such as finding, searching, and explaining. It can respond quickly and naturally. It does not need to boot a computer to answer a simple question.
DeepWork is the execution layer. When a request requires real investigation, multiple steps, large datasets, code, validation, or a long-running workflow, Polly creates a DeepWork task. That agent gets the full environment: our CLI, files, Python, and hundreds of how-to guides that encode how to work inside Polyform.
Polly stays in the conversation while DeepWork does the job. It can tell the user what is happening, receive updates, and bring the result back into the main thread. The user can also open the task and see the work directly.
The important part is not merely that we have multiple agents. It is that each layer has a different job, cost profile, and interaction contract.
Polly is optimized for latency, conversational continuity, and judgment about what should happen next. DeepWork is optimized for flexibility, persistence, and correctness. The system spends expensive reasoning only when the task earns it.
This is the first version that has felt right on all three dimensions: capability, cost, and user experience.
We are not the only ones moving in this direction
I do not think this pattern is unique to Polyform. The industry is converging on a similar separation between immediate interaction and delegated work.
OpenAI explicitly distinguishes quick search and conversation from Deep Research, which is meant for multi-step questions and can run while the user follows its progress. Its own guidance says standard chat is faster for quick requests and Deep Research is appropriate when depth is required. OpenAI's Deep Research guide describes that product boundary directly.
Codex applies the same principle to software work: a user delegates a task into a separate environment, monitors it, and reviews the result when it is ready. It does not pretend that a 20-minute engineering task should behave like autocomplete.
Anthropic has also described an architectural change in Claude Cowork that feels especially relevant. It moved the main agent loop outside the virtual machine while keeping code execution isolated inside it. One benefit is that the conversational agent can still respond even if the execution environment fails. Anthropic's engineering write-up approaches the question through security, but the product lesson is similar: the interface and the execution environment do not need to be the same thing.
These are not identical systems, and I would not claim they are. But they point toward the same product truth: conversation is the control plane; deep work is a delegated execution mode.
What I would tell anyone building an agent
If I were starting again, I would keep five principles in front of me.
Most user interactions are small. Answer them with the fastest, cheapest system that can do the job well. Escalation should be a capability, not the default.
Agents become much more reliable when they can discover and compose capabilities. For us, that meant a CLI with consistent authentication, help, and coverage of the full product.
Context windows are valuable reasoning space, not a place to dump every object the system can fetch. Save the data, point the agent to it, and let tools retrieve only what matters.
Our DeepWork agents have hundreds of how-to files. Those are not prompt hacks. They are the operating manual for the product, made legible to both humans and agents.
Long-running work feels broken when the user cannot tell whether anything is happening. A task should have progress, a place to inspect it, and a clear path back to the original conversation.
The agent should feel simple, even when the work is not
The arc of this project has been a gradual removal of complexity from the user's experience.
We began with a simple-looking chatbot whose internals became increasingly tangled. We then built an extraordinarily capable coding agent whose power was impossible to use casually. The best version came from combining the strengths of both without pretending they were the same thing.
Polly talks with you. DeepWork goes away and does the work. The product decides how much machinery the moment deserves.
That sounds obvious now. It took us five versions to learn it.