Agentic Primitives 101智能体基础入门

Inside the harnesses that let AI carry a job across hours, days, and conversations.深入了解那些让 AI 能够跨越数小时、数天乃至多轮对话完成工作的“支撑架构”。

I’m exploring making some video content with folks who are getting real value from AI (or could get real value with some help), especially for unexpected work or via interesting stories. If that sounds like you or someone you know, I’d love to chat!我正在考虑与那些从 AI 中获得真正价值（或在某些帮助下能够获得价值）的人们一起制作一些视频内容，特别是针对非预期工作或通过有趣故事呈现的内容。如果你或你认识的人符合这种情况，我很乐意交流！

---

I’m old enough to remember 2024, which many people dubbed the “year of the agent”. It seemed like every SaaS company was trying to add some sort of agent-powered product or feature to its software.¹ 我年纪够大，还记得 2024 年，那一年被许多人称为“智能体之年”。当时似乎每家 SaaS 公司都在试图为其软件添加某种由智能体驱动的产品或功能。

Everybody had this feeling that agents were going to be the next big evolution in AI, but nobody quite understood what that meant. But then, a funny thing happened: around late 2025/early 2026, agents started getting good.每个人都有一种预感，认为智能体将是 AI 的下一次重大演进，但没人真正理解这意味着什么。然而，有趣的事情发生了：大约在 2025 年末到 2026 年初，智能体开始变得好用了。

You may have seen the (in)famous METR chart, which shows the length of software tasks that coding agents can complete (relative to how long a human expert would take). GPT-4 could do tasks on the order of a few minutes. By 2026, we had models like Mythos reaching tasks on the order of tens to hundreds of hours. ²你可能见过那张（臭）名昭著的 METR 图表，它展示了编码智能体所能完成的软件任务时长（相对于人类专家所需的时间）。GPT-4 可以处理分钟级的任务。到了 2026 年，我们有了像 Mythos 这样的模型，能够处理几十到几百小时的任务。

This chart hasn’t been updated in six months. With the advent of models like Astra, Mythos, and Fable, we’ve reached a point where it’s increasingly challenging (if not impossible) to keep building harder and harder tasks that generate meaningful measurements of how long models can work.这张图表已经有六个月没有更新了。随着 Astra、Mythos 和 Fable 等模型的出现，我们已经达到这样一个地步：想要构建出更难的任务来衡量模型的工作时长，变得越来越具有挑战性，甚至是不可能的。

But models have kept working longer all the same³. And as models have gotten better, we’ve had to think much more about the software around them.但模型依然在持续工作更长时间。随着模型性能的提升，我们不得不更多地思考围绕它们构建的软件。

At the beginning of the year, we were tentatively calling this the harness.今年年初，我们暂且将此称为“支撑架构”（harness）。

A harness is the set of constraints, tools, documentation, and feedback loops that keep an agent productive and on track. Think of it as the difference between dropping a new hire into a company with no onboarding versus one with clear architecture docs, linting rules, a fast CI pipeline, and well-defined module boundaries.支撑架构是一套约束、工具、文档和反馈循环，用以保持智能体的生产力并使其保持在正确的轨道上。可以将其理解为：让一名新员工入职，一家公司没有任何入职指引，而另一家公司则拥有清晰的架构文档、代码检查规则、快速的 CI 流水线以及定义明确的模块边界，这两者之间的区别。

The Emerging "Harness Engineering" Playbook新兴的“支撑架构工程”指南

I remember reading a blog post from Thorsten Ball called How to Build an Agent - before we landed on the “harness” name. What struck me about it at the time was how simple the agent loop was at its core: a user sends a prompt, the model calls tools, gets the results or errors back, decides what it should do next, and keeps performing this loop on repeat.我记得在确定“支撑架构”这个名称之前，读过 Thorsten Ball 写的一篇名为《如何构建智能体》的博文。当时它让我印象深刻的是其核心智能体循环的简洁：用户发送提示词，模型调用工具，获取结果或错误，决定下一步做什么，并重复执行这个循环。

You could call the code that helps the model run this loop an early version of a harness. And what I’ve found interesting about the broader landscape this year is how quickly we’ve converged on a handful of shared primitives for building genuinely useful, long-running agents.你可以把辅助模型运行此循环的代码称为支撑架构的早期版本。今年，让我对更广阔的领域感到有趣的是，我们如何如此迅速地收敛到少数几个用于构建真正有用、长效运行智能体的共享原语上。

I wouldn’t necessary call these “stable” or “mature,” just yet, but they seem to be becoming table stakes for agents much in the same way that SQL databases, REST APIs, and MVC frameworks were table stakes for applications in the 2010s.我未必会称这些原语已经“稳定”或“成熟”，但它们似乎正在成为标配，就像 2010 年代的 SQL 数据库、REST API 和 MVC 框架对于应用程序一样。

I tend to think of those features as falling into three different buckets: doing the work, continuing the work, and delegating the work⁴.我倾向于将这些功能分为三类：执行工作、延续工作和委派工作。

Doing the work

执行工作

There are a few primitives that fall in this first bucket: instructions and skills, tools and connectors, and sandboxes. These give the agent the context and access it needs, along with a computer on which to do its work.第一类中有几个原语：指令与技能、工具与连接器，以及沙箱。这些为智能体提供了所需的上下文和访问权限，以及执行工作的计算环境。

Instructions and skills

指令与技能

Instructions have been around for quite a while - since the earliest ChatGPT/GPT-3 days. System prompts and developer prompts give the model standing instructions at every turn, at the cost of continuously including them in the context window. This is useful for things you always want the agent to take into account whenever it’s working: “Ask me before you publish anything,” for example.指令已经存在很长一段时间了——从最早的 ChatGPT/GPT-3 时代就开始了。系统提示词和开发者提示词在每一步都为模型提供常驻指令，代价是必须持续将其包含在上下文窗口中。这对于你希望智能体在工作时始终考虑的事项非常有用，例如：“在发布任何内容之前先问我”。

Skills take a different approach. They package natural language, often alongside executable scripts, in a way that’s designed for the agent to read when it needs to. They can go into far more detail and include task- or role-specific context you don’t want in the model’s context window all the time. Think of a launch checklist where the agent needs to check twenty different things before we consider a project ready for launch.技能则采取了不同的方法。它们将自然语言（通常与可执行脚本一起）打包，设计成供智能体在需要时读取的形式。它们可以包含更详细的内容，并涵盖那些你不想一直放在模型上下文窗口中的任务或角色特定上下文。想象一个发布检查清单，智能体在认为项目准备好发布之前，需要检查二十个不同的事项。

From my previous post on skills, tools, and MCPs:摘自我之前关于技能、工具和 MCP 的文章：

Models need guidance on when and how to use their capabilities effectively. Just because a model can call a PDF manipulation library doesn’t mean it knows the proper sequence of operations to fill out a form cleanly, or how to preserve formatting, or what quality standards to aim for.模型需要关于何时以及如何有效利用其能力的指导。仅仅因为模型可以调用 PDF 处理库，并不意味着它知道如何清晰地填写表格、如何保留格式，或者应该追求什么样的质量标准。

Technically, we know how to solve this problem: develop extensive prompts that detail the process, define edge cases, and preemptively address issues. But we haven’t had a standardized way to share “prompts that work,” nor have we had good patterns for managing them, such as version control and collaboration.从技术上讲，我们知道如何解决这个问题：开发详尽的提示词，详细说明流程、定义边界情况并预先解决问题。但我们还没有一种标准化的方式来分享“有效的提示词”，也没有好的模式来管理它们，例如版本控制和协作。

Skills, Tools and MCPs - What’s The Difference?技能、工具和 MCP —— 有什么区别？

Tools and connectors

工具与连接器

Similarly, tools were part of the very first agent loops. They’re essentially a way to tell the model: you have access to this software function. If you decide you need to call it, let me know, I’ll execute it for you, and then give you the results back.同样，工具是最初智能体循环的一部分。它们本质上是一种告诉模型的方法：你可以访问此软件函数。如果你决定需要调用它，请告诉我，我会为你执行，然后把结果反馈给你。

But tools have come a long way. We’ve expanded into connectors, plugins, apps - whatever you want to call them - to give our agents more efficient and effective hooks into the wider world of software. We’ve gone from exposing tools that our software is expected to run locally, to giving agents more autonomy to call MCP servers or execute CLI commands.但工具已经发展了很多。我们已经扩展到连接器、插件、应用程序——无论你怎么称呼它们——以便为我们的智能体提供更高效、更有效的钩子，接入更广阔的软件世界。我们已经从仅仅暴露我们的软件预期在本地运行的工具，转向赋予智能体更多自主权去调用 MCP 服务器或执行 CLI 命令。

Not everything will necessarily become a tool. I think about my most used apps like Slack or GitHub, and at some level, the model might be able to get by without an official connection - as computer use has gotten better, an agent can simply click through Slack or GitHub using a browser like we would. But that’s far less effective than having direct access via a CLI or MCP, so I suspect we’ll keep evolving tools and connectors for quite a while⁵.并非所有东西都一定会成为工具。我想起我最常用的应用，如 Slack 或 GitHub，在某种程度上，模型可能无需官方连接也能应付——随着计算机使用能力的提升，智能体可以像我们一样简单地通过浏览器点击 Slack 或 GitHub。但这远不如通过 CLI 或 MCP 直接访问有效，所以我怀疑我们将长期持续改进工具和连接器。

Sandboxes

沙箱

One major trend we’ve seen is agents moving from working on your device to working in the cloud. As part of that, they need a cloud computer to do their work. When you’re running Codex or Claude Code locally, they can use your computer. As you move things into the cloud, you have to give the agent its own environment - i.e., a sandbox.我们看到的一个主要趋势是智能体从在你的设备上工作转向在云端工作。作为其中的一部分，它们需要一台云端计算机来完成工作。当你本地运行 Codex 或 Claude Code 时，它们可以使用你的计算机。当你把事情转移到云端时，你必须给智能体它自己的环境，即沙箱。

This is more complicated than it seems. We’re used to thinking of software as a series of short-lived, ephemeral requests, and now we have these things that need to work for hours on end while retaining access to a persistent compute environment. We need to securely manage networking, generate artifacts and files, and make those available to the outside world. Ideally, the agent should also be able to use all the same connectors and plugins it would normally use on your laptop.这比看起来要复杂得多。我们习惯于将软件视为一系列短暂的请求，而现在我们有了这些需要持续工作数小时，同时保持对持久计算环境访问权限的东西。我们需要安全地管理网络、生成工件和文件，并使它们对外部世界可用。理想情况下，智能体还应该能够使用它在你的笔记本电脑上通常使用的所有相同的连接器和插件。

Sandboxes are useful for taking on larger pieces of work, but they also have an added benefit of helping manage context. As we give agents larger and more complex tasks, they’re often going to need to look through mountains of data (e.g. looking through gigabytes of server logs to investigate an outage), and sandboxes can exist as a place to offload the computation without taking up precious space in the model’s context window.沙箱对于承担更大规模的工作很有用，但它们还有一个额外的好处，即帮助管理上下文。当我们给智能体分配更大、更复杂的任务时，它们往往需要查看海量数据（例如查看数 GB 的服务器日志来调查故障），沙箱可以作为一个卸载计算任务的地方，而不会占用模型上下文窗口中宝贵的空间。

This is the basic idea behind “code mode,” or programmatic tool calling. The agent gets access to tools through a programming interface and writes code that calls them. In this case, you can imagine writing code to deterministically sift through the mountain of logs before returning what’s actually relevant to the model.这就是“代码模式”或程序化工具调用的基本思想。智能体通过编程接口访问工具，并编写调用这些工具的代码。在这种情况下，你可以想象编写代码来确定性地筛选海量日志，然后再将真正相关的内容返回给模型。

Continuing the work

延续工作

Once an agent can do the work, we need ways for it to keep going: like sessions, compaction, and schedules.一旦智能体能够执行工作，我们就需要让它持续下去的方法：例如会话、压缩和调度。

Sessions

会话

Sessions are a primitive you don’t necessarily need, but they’re convenient, and they let you start to bake in a lot of other things. With a stateless API, you send an input, get an output, and chain those together yourself. A session gives you a place to accumulate conversation history, tool invocations, and the other context that builds up as an agent works. ⁶会话是一个未必必需但很方便的原语，它让你开始整合许多其他功能。对于无状态 API，你需要发送输入、获取输出，并自己将它们串联起来。会话为你提供了一个积累对话历史、工具调用以及智能体工作时产生的其他上下文的地方。

Compaction

压缩

Then there’s compaction, which I still find pretty magical. A year and a half ago, I was the type of person who would always create new threads in ChatGPT when I was working on different things. I was kind of afraid of, or perhaps paranoid about, context window pollution.接下来是压缩，我仍然觉得这非常神奇。一年半前，我在处理不同事情时总是会在 ChatGPT 中创建新线程。我有点害怕，或者说对上下文窗口的污染感到担忧。

I worried that the model would do a worse job on my coding tasks because I’d previously asked it about shopping. I worried that I’d run out of context window because of irrelevant things, and the model would start forgetting important stuff I’d told it. Now in 2026, I don’t worry about any of that with Codex. It works continuously for hours or days on various things, and I don’t really worry about its short-term memory anymore. ⁷我担心模型会因为我之前问过它购物的事情而在编码任务上表现不佳。我担心会因为无关紧要的事情耗尽上下文窗口，导致模型开始忘记我告诉过它的重要内容。现在到了 2026 年，我在使用 Codex 时完全不用担心这些。它可以在各种事情上持续工作数小时或数天，我真的不再担心它的短期记忆了。

Compaction reduces the conversation the model carries forward. In some harnesses this happens automatically, but there are ways to manually tune your own applications to use compaction. With Codex, the model gets encrypted “summaries” that it’s able to use moving forward.压缩减少了模型向前传递的对话内容。在一些支撑架构中，这是自动发生的，但也有方法可以手动调整你自己的应用程序来使用压缩。对于 Codex，模型会获得加密的“摘要”，它能够利用这些摘要继续工作。

One way to think about compaction is a way to unlock better “short-term memory” - the model is still forgetting some things, but it’s increasingly good at forgetting the things that weren’t useful to the work it was doing.思考压缩的一种方式是将其作为解锁更好“短期记忆”的途径——模型仍然会忘记一些事情，但它越来越擅长忘记那些对当前工作无用的信息。

Schedules and events

调度与事件

I think OpenClaw deserves a lot of credit for making heartbeats a more visible part of how people think about agents. In the previous paradigm, nearly everything agents did was turn-based and driven by user prompts. 我认为 OpenClaw 在使心跳机制成为人们思考智能体方式中更显眼的一部分方面功不可没。在之前的范式中，智能体所做的一切几乎都是基于回合的，并由用户提示驱动。

But what if we just woke these agents up on a schedule? Or woke them up based on certain events? 但是，如果我们只是按计划唤醒这些智能体呢？或者根据特定事件唤醒它们？

You can trigger an agent to check for work, and then either do the work or do nothing and send no message to the user. As simple as this sounds, making it a first class primitive for harnesses has been a major productivity unlock for me. It turns out there’s quite a lot of work that needs to get done either on a regular schedule, or needs to wait for some event which an agent can check for on a regular schedule.你可以触发智能体去检查是否有工作，然后要么执行工作，要么什么都不做，也不向用户发送任何消息。尽管听起来很简单，但将其作为支撑架构的一等原语对我来说是一个重大的生产力解锁。事实证明，有很多工作需要按固定计划完成，或者需要等待某些事件，而智能体可以按固定计划检查这些事件。

OpenAI recently added support for MCP Events, which lets plugins trigger work when something happens in a connected application. They can roughly be thought of like webhooks, but they give MCP servers a way to advertise the events it supports upfront and register subscriptions. OpenAI 最近增加了对 MCP 事件的支持，这允许插件在连接的应用程序中发生某些事情时触发工作。它们可以大致被视为 Webhook，但它们为 MCP 服务器提供了一种预先通告其支持的事件并注册订阅的方法。

ChatGPT creates a subscription, and the server sends matching events to the subscribed chat, where ChatGPT can pick up the work using the instructions already established there.ChatGPT 创建一个订阅，服务器将匹配的事件发送到已订阅的聊天中，ChatGPT 可以在那里使用已经建立的指令接手工作。

Delegating the work

委派工作

The main primitive in this category is subagents. We’re still figuring out what it means for a model to be good at using them, and I think increasingly that’s a behavior you train into the model itself. That includes delegating to subagents and collaborating with other agents as equals or peers.这一类别中的主要原语是子智能体。我们仍在探索模型擅长使用它们意味着什么，而且我越来越认为这是一种你应该训练模型本身具备的行为。这包括委派给子智能体，以及作为平等伙伴或同行与其他智能体协作。

You can have a main agent give a subagent a bounded assignment and let it work in its own context. The subagent can return its findings without putting every intermediate tool call into the main agent’s conversation. That can help avoid context pollution, but the main agent still has to check what came back and combine the results. Note: subagents will also burn through your token budgets faster!你可以让主智能体给子智能体分配一个有边界的任务，并让它在自己的上下文中工作。子智能体可以返回其发现结果，而无需将每个中间工具调用都放入主智能体的对话中。这有助于避免上下文污染，但主智能体仍然必须检查返回的结果并进行整合。注意：子智能体也会更快地消耗你的 Token 预算！

Another way to think about it is spinning off peers. Agents can create other threads or nudge existing ones, and you can start to orchestrate agents working in groups without necessarily having a centralized system. 另一种思考方式是分拆出同行。智能体可以创建其他线程或推动现有线程，你可以开始编排成组工作的智能体，而不必非要有一个中心化系统。

We’re still exploring what these different forms of collaboration are good at, but it’s becoming increasingly clear that parallelism may be another scaling axis - the AI that solved the Navier-Stokes Millennium Prize Problem was in fact a group of around ten thousands agents. 我们仍在探索这些不同形式的协作擅长什么，但越来越明显的是，并行性可能是另一个扩展维度——解决了纳维-斯托克斯千禧年大奖难题的 AI 实际上是一个由大约一万个智能体组成的群体。

Emerging patterns

新兴模式

We’ve started to converge on the pieces an agent needs to do useful work. But as agents work for longer and become more involved in our lives, I think we’re going to need more than what we’ve covered so far. Three areas I’m watching are memory, proactivity, and identity.我们已经开始在智能体执行有用工作所需的组件上达成共识。但随着智能体工作时间变长并更多地参与到我们的生活中，我认为我们将需要比目前涵盖的更多内容。我正在关注的三个领域是记忆、主动性和身份。

Memory

记忆

What should be remembered over time? There’s a rich history here, and we’ve tried many things in the LLM era to get good long-term memory. We touched on compaction as a pretty workable short-term memory, but as things get compacted over days or weeks, you need a system to remember details and important context for longer.随着时间的推移，什么应该被记住？这方面有着丰富的历史，在 LLM 时代我们尝试了许多方法来获得良好的长期记忆。我们提到了压缩作为一种相当可行的短期记忆，但随着信息在几天或几周内被压缩，你需要一个系统来更长久地记住细节和重要的上下文。

Some early experiments used simple Markdown files locally. Other approaches identify facts about the user, save them, and bring them back into context. We’ve also had embedding-based retrieval systems that encode semantic information, and hybrid systems that combine these approaches.一些早期实验在本地使用了简单的 Markdown 文件。其他方法识别关于用户的事实，保存它们，并将它们带回上下文中。我们还有基于嵌入的检索系统来编码语义信息，以及结合这些方法的混合系统。

Ultimately, I think we’re going to have to keep combining systems. I do like the combination of short-term compaction and some sort of long-term durable memory. It mirrors the way we talk about human memory in laypeople’s terms, and that feels like a useful way to think about it.归根结底，我认为我们将不得不继续结合各种系统。我确实喜欢短期压缩与某种长期持久记忆的结合。它反映了我们用通俗语言谈论人类记忆的方式，这感觉是一个有用的思考角度。

Proactivity

主动性

What interests me about proactivity is that we can start to see the path toward ambient AI, something I’ve wanted for quite a while now. The idea is that eventually intelligence is going to be all around us, with access to the context it needs to help without waiting for us to start every interaction.关于主动性，我感兴趣的是我们可以开始看到通往环境 AI（ambient AI）的路径，这是我期待已久的事情。其思想是，最终智能将无处不在，并能获取所需的上下文，无需等待我们发起每一次交互就能提供帮助。

Think about a smart email assistant. A lot of the first wave of AI email products amounted to a chat sidebar next to your inbox, where you could ask it to summarize things or archive emails for you. What I actually want is an assistant that has access to my email, notices when something important comes in, and alerts me with a suggested reply already written, for me to review and approve.想想智能电子邮件助手。第一波 AI 电子邮件产品大多相当于收件箱旁边的聊天侧边栏，你可以在那里要求它总结内容或为你归档邮件。我真正想要的是一个能够访问我的电子邮件、注意到有重要事项进入、并用已经写好的建议回复提醒我，供我审查和批准的助手。

In effect, this creates a new type of agent loop. Events and new information keep feeding into the same ongoing process, and the model decides whether to do work, leave things alone, or reach out to us. Messaging the user becomes one of many tool calls it might take, and a message to humans doesn’t have to be the end of the job.实际上，这创造了一种新型的智能体循环。事件和新信息不断输入到同一个持续的过程中，模型决定是执行工作、搁置一边，还是联系我们。向用户发送消息成为它可能采取的众多工具调用之一，而向人类发送消息不必是工作的终点。

Identity

身份

Historically, I think there have been two philosophies here. The first is impersonation: the agent assumes my identity and goes out into the world as me. The other is delegation: the agent has its own identity, accounts, and credentials, and the world understands it as an agent.从历史上看，我认为这里有两种哲学。第一种是冒充：智能体承担我的身份，并以我的名义进入世界。另一种是委派：智能体拥有自己的身份、账户和凭证，世界将其理解为一个智能体。

In the last few months, my thinking has shifted on this. I now feel that 90%-ish of the things you’d want to do should probably be delegation rather than impersonation. In the vast majority of situations, I don’t want to give an agent full read and write access to everything I have⁸.在过去几个月里，我的想法发生了转变。我现在认为，你想要做的 90% 左右的事情应该是委派，而不是冒充。在绝大多数情况下，我不想给智能体我所拥有的一切的完全读写访问权限。

There’s a very rough analogy to an API key or service account, which can have limited permissions relative to a full human user. I feel like we’re approaching something analogous with agent accounts, and we’ll likely need some new protocols or standards around how we give them access to things.这与 API 密钥或服务账户有一个非常粗略的类比，它们相对于完整的人类用户可以拥有有限的权限。我觉得我们正在接近智能体账户的类似物，我们很可能需要一些关于如何赋予它们访问权限的新协议或标准。

Either approach can have restricted permissions. Giving an agent its own identity lets other people and systems distinguish its actions from mine; we still have to decide what that identity is allowed to do.两种方法都可以有受限的权限。赋予智能体自己的身份可以让其他人和其他系统区分它的行为与我的行为；我们仍然必须决定该身份被允许做什么。

For example, perhaps an agent can read all of my email and maybe send email to a handful of whitelisted recipients or other agents, but otherwise can’t just blanket-send email. It feels like we’re going to need ways to grant permissions at that level of granularity - which we don’t yet have.例如，也许智能体可以读取我所有的电子邮件，并可能向少数列入白名单的收件人或其他智能体发送电子邮件，但除此之外不能随意群发邮件。感觉我们需要在那种粒度级别上授予权限的方法——而我们目前还没有。

The next checkpoint

下一个检查点

We’re starting to see these pieces come together in products like OpenAI’s dots (and Muse/Instinct/Grok Bot), which combine memory, connected tools, and proactive work between conversations. You can give a dot an ongoing responsibility, and it can keep making progress while you’re doing something else. It has its own computer in the cloud, and you choose which applications it can access and when it needs your approval.我们开始在 OpenAI 的 dots（以及 Muse/Instinct/Grok Bot）等产品中看到这些组件组合在一起，它们结合了记忆、连接工具以及跨对话的主动工作。你可以给一个 dot 分配持续的职责，它可以在你做其他事情时继续取得进展。它在云端有自己的计算机，你可以选择它能访问哪些应用程序以及何时需要你的批准。

This is where the path toward ambient AI starts to feel more concrete. I want an agent that can take things off my plate, do work in the background, and reach out when it needs me. There’s still quite a lot to figure out about how to make that dependable. But these primitives give us enough to start building that kind of relationship with our software, and to learn where the next pieces are missing.这就是通往环境 AI 的路径开始变得更加具体的地方。我想要一个能够分担我的工作、在后台执行任务并在需要我时联系我的智能体。关于如何使其可靠，还有很多需要解决的问题。但这些原语给了我们足够的条件，开始与我们的软件建立那种关系，并了解哪些部分是缺失的。

1. Maybe what’s worse, if you asked ten different people for the definition of an agent, you’d probably get ten different answers.

2. The task lengths in the METR chart are measured by human expert completion time at a given level of agent reliability. They don’t measure the agent’s own runtime. METR’s published page cautions that measurements above sixteen hours are unreliable with its current task suite. My understanding of why METR has stopped updating the chart comes from a talk given by a METR employee.

3. Personally, I’ve seen a model work for about six weeks on a task.

4. There’s a lot I haven’t touched on here. This doesn’t quite get into multimodality, for example: image, audio, and video inputs. As we build more complex harnesses and approach AGI, I think we’ll need to figure out how to make seeing, hearing, and speaking part of the same ongoing work.

I’ve also mostly been looking through the lens of an individual building or using a harness. There’s quite a lot at the team and organizational level that we’re still figuring out, including basic things like sharing skills. Right now, that seems to be getting solved at the product layer. Depending on how a product handles skills, I think there’s some potential for product lock-in there.

5. This also reveals an interesting tidbit: our agents still need to use all the software we do. They need to collaborate with humans and teams. It’s not enough to say, “I’m going to build an agentic Slack and call it a day,” or an agentic Gmail and call it a day. Your agents have to be able to use the same tools you do, at least for now.

6. Sessions are one of the fundamental primitives of the Agents API. OpenAI previously tried to approximate something like this with the Assistants API, which was perhaps its first foray into building an agentic API. But in my view, the model and the tools around it weren’t sufficiently powerful at the time to justify offloading so much to the cloud or to a third party.

7. For what it’s worth, I still do create a lot of new threads, but they’re to help me stay organized and focused, not the model.

8. And I’m also sidestepping the question of what level of disclosure we should normalize around when you’re interacting with an agent vs a human. Should you know when your coworker is using an agent to send you a Slack message or email? Should you know when a prospective customer is using an agent to call to book an appointment?