A coding agent has a user interface, a model, and a harness that connects the model to tools and user requests.
2
Teams can avoid rebuilding their agent infrastructure for every model release by using a stable harness such as Codex and treating models as interchangeable components.
3
Codex can be used directly or through its SDK, GitHub integration, TypeScript and Python interfaces, and MCP connectors to build coding and non-coding products.
Summary
Bill Chen and Brian Fioca describe a coding agent as three parts: a user interface, a model, and a harness. The harness contains the prompts, tools, and agent loop that let a model work across turns, inspect code, edit files, and run commands. They explain why maintaining this layer is difficult as models, APIs, context handling, security requirements, and tool behavior change. Their proposed answer is to use Codex as a maintained harness and abstraction layer, rather than rebuilding those pieces around every new model. Codex runs in places such as VS Code, the CLI, chat, Slack, and GitHub, and can also be embedded in other agents through an SDK. The speakers describe integrations with GitHub, Cursor, VS Code, and Zed. They also argue that terminal access lets Codex handle tasks beyond software development, such as organizing photos or analyzing CSV files. The talk ends with a prediction that longer task horizons and higher trust will expand what the SDK and its agents can do.
A coding agent combines an interface, a model, and a harness
Bill Chen reduces a coding agent to three parts: a user interface, a model, and a harness. The interface might be a CLI tool, an integrated development environment, a cloud agent, or a background agent. The model provides the coding ability. The harness is the layer that combines prompts and tools in an agent loop, then handles input and output from the model. The talk focuses on the harness because models are released often and teams keep having to adapt their agents to them.
The harness connects the model to users, code, and tools
Brian Fioca defines the harness as the interface layer around the model. It gives the model a way to talk to users, inspect and modify code, and perform actions with tools. It must support many turns, interpret what a user wants, and help the model write code. The speakers say the harness can contain a product's special sauce, but building one well requires work across prompts, tools, context handling, and the rest of the agent loop.
A model's learned habits affect how prompts should be written
The speakers describe model behavior as intelligence plus habit. A model has technical abilities, such as knowing languages and frameworks, and it also has learned ways of solving problems. OpenAI models were trained to plan, inspect their surroundings, gather context, think before editing, and test their work. When GPT-5 launched, some teams reused prompts written for other models and told it to inspect every file before editing. The model followed those instructions too thoroughly and became slow. When asked what was taking so long, it explained that the prompt was making it inspect everything unnecessarily.
Codex packages a complex coding harness across many interfaces
Codex is presented as an agent for places where people code. It is available as a VS Code plugin and CLI, can be called from the cloud or ChatGPT on a phone, and can work through Slack and GitHub. It can turn a specification into runnable code, make a plan, navigate a repository, edit files, run commands, execute tasks, and review pull requests. Supporting these workflows requires parallel tool calls, thread merging, sandboxing, permissions, port management, prompt forwarding, context compaction, MCP support, and image handling.
Terminal access lets Codex handle tasks outside software development
The speakers describe Codex as a computer-use agent for the terminal. Tasks that can be expressed through command-line tools and files do not have to be conventional coding tasks. They use organizing photos from a desktop as a simple example. Codex can also analyze large amounts of CSV data in a folder. The underlying idea is that many computer tasks can be expressed by writing and chaining commands, so a terminal-capable agent can work beyond source code.
A maintained harness can become the abstraction layer for other products
The speakers recommend putting effort into the product's differentiated experience while using Codex as the harness layer. This means teams do not need to optimize prompts and tools again for every model upgrade. They reject the idea that this is only a wrapper because the infrastructure handles the hard parts that change with the models. They describe Codex as an SDK with TypeScript and Python interfaces, a GitHub Action for tasks such as resolving merge conflicts, and the ability to connect to the Agents SDK and MCP connectors.
Agents can create connectors and software around their own tools
The talk describes a progression from chatbots, to chatbots with tools, to chatbots that can create tools they do not already have. With this pattern, enterprise software could write API-level plugin connectors for individual customers while it is being used. The speakers say this could replace work that previously required a professional services team. They also mention a Kanban board that could fix its own bugs, as an example of software that can act on itself.
Partners can use Codex directly or adapt its model and harness
Zed wrapped Codex in an IDE interface so its team could focus on the code editor rather than reproduce Codex's agent capabilities. GitHub integrated with Codex through the SDK and can use it in CI/CD pipelines. Cursor took a more customized approach. The Cursor team aligned its tools with the distribution used to train the Codex model and aligned its harness with the open-source Codex CLI implementation. The speakers say that source code is publicly available to fork and use.
Longer task horizons will raise the work agents can handle
The speakers expect models to improve at longer tasks that run without supervision, which will raise the level of work they trust agents to perform. They point to sprawling codebases, non-standard libraries, closed-source environments, and existing templates and practices as future challenges. They expect the SDK to evolve so models can learn during a task, avoid repeating mistakes, and get more support for writing code and using a terminal to solve problems.
