Agent builders should begin with a framework, then move to custom state-machine code when the product needs more control.
2
Every addition to an agent can reduce its performance, so prompts, branching logic, and old code should be pruned aggressively.
3
Kanban is a useful interface for supervising several inference-bound agents, while cloud execution removes local setup and dependency limits.
Summary
Ara Khan argues that agent development has four maturity levels. Teams can start with an existing framework to test whether an idea works, write their own state-machine agent when they need control, manage parallel agents through a Kanban interface, and move execution to the cloud for scale. His practical advice for custom agents is to model every agent as a recursive loop with explicit states, remove unnecessary instructions, make the agent easy to build and test through a CLI, have a human think through the architecture, and learn the exact API requirements of frontier models. Khan says newer models can perform worse when system prompts become too large, and reasoning traces must be passed in the expected format. He also describes cloud agents running long tasks from a phone or laptop, including iterative UI testing. The talk is direct about the cost of generating code faster than engineers can understand its design.
Frameworks are useful for testing an agent idea quickly
Khan places framework use at the first level of agent maturity. If a team is testing product-market fit for a simple task, such as aggregating emails, an agent framework can produce something usable quickly. He names LangChain and LangGraph as examples, although he does not use them at Cline. Frameworks help establish that an agent can solve the problem before the team invests in a custom implementation. Khan says their limits appear when a serious production system needs more customizability, modularity, and room for future changes. At that point, he recommends writing the agent directly rather than depending on the framework's abstractions.
Every agent should be understood as a state machine
Khan says every agent is ultimately a recursive loop, a while loop with conditions and end states. The useful mental model is to know the agent's current state at any point. In his example, a task to read files and explain them moves from the user task to a state that reads the files, invokes a tool, checks that the files were read, and then calls a completion tool. The state machine ends at task complete. The same model can describe a short interaction or a process that runs for hours. Khan argues that visualizing these transitions makes agent design easier because the builder can reason about what the agent is doing instead of treating it as an opaque sequence of model calls.
Extra instructions can make frontier models perform worse
Khan's second rule is that every addition to an agent risks making it worse. He includes large system prompts, many edge cases, and elaborate if-else logic in the things that can get in the model's way. His advice is to remove instructions and repeatedly prune the system until only what is needed remains. He gives the Codex repository as an example, saying the prompt for GPT-5.3 is one-third the size of the prompt for GPT-5. In his explanation, newer frontier models can become overwhelmed by too many instructions and lose track of the right action. Cline's team went as far as rewriting the product from scratch after finding too much older code and accumulated junk.
A CLI lets other coding agents build and test the agent
Khan's third rule is to make the agent an easy part of what he calls a pseudo-RL pipeline. The practical requirement is a CLI or similar interface that makes the agent easy to build and test. He wants coding agents to be able to modify the agent, run it, test it end to end, and repeat the cycle. That can include an agents.md file, appropriate skills, and CI or CD. Khan describes a long-running agent working in a parallel thread, making changes and testing them without requiring a person to guide every step. The design becomes difficult to improve when the agent itself is difficult to build or test. A simple development interface therefore affects how effectively agents can work on the agent's code.
Human engineers still need to think through the architecture
Khan's fourth rule is not to build slop. Fast token generation makes it easy to produce a lot of code before anyone has considered whether the design makes sense. He recommends spending time on the architecture, the state machine, and the agent's intended behavior. Engineers do not need to write every line by hand, but they should read the code and decide how the system is structured. Khan says the architecture of an agent has to be done thoughtfully by a human, even when a model helps with the design conversation. His concern is that letting another model generate the whole implementation without this planning creates systems whose behavior and state transitions are hard to understand.
Exact frontier-model API handling affects performance
Khan's fifth rule concerns the APIs of frontier model providers. He says newer models such as Opus 4.6, Gemini 1.5 Pro, and GPT-5.3 use reasoning traces that are part of caching and test-time computation. In multi-turn conversations, those traces need to be sent in the precise format expected by the provider. A request can still return a response when the format is wrong, but performance can degrade without an obvious error. Khan warns that an abstraction such as OpenRouter does not remove the need to understand and test each provider's API behavior. He also says the APIs have asymmetries that can make it harder to switch between providers, so teams should verify that each integration is working as intended.
Kanban fits work where several agents run in parallel
Khan recommends Kanban boards as the user interface for agents. His reasoning is that agent work is often inference-bound. While one agent runs for several minutes, a person can start another task rather than wait. Multiple agents may run at once and potentially mutate related source, so their state and work need to be isolated. A Kanban board gives the person a view of all active agents and the status of each task. Khan compares the operator to an engineering manager and the agents to individual contributors. The board also supports dependencies, such as waiting for two tasks to finish before starting another. He says he made this proposal on March 26 and later saw Claude Code release a similar interface.
Cloud agents remove local setup limits and support long tasks
The fourth level is moving agent execution to the cloud. Khan argues that teams should avoid making every user install complex local workflows when a shared cloud setup can do the work once. Cloud agents can run on separate machines, set up their own environments, and avoid local dependencies. He describes sending tasks from his phone that run for 15 to 20 minutes, including building a VS Code extension and testing a sequence of UI actions. Some tasks can continue for 50 to 60 minutes while the agent retries when something does not work. Several tasks can run in parallel, after which the engineer can pull down the resulting pull requests. Khan sees Kanban as the main interaction model and cloud machines as the place where most of the compute happens.
