以行为为中心的 AI 设计

行业正在经历构建 AI 系统方式的根本转变：从早期实验走向大规模生产使用。当前以 Agent 为中心的方法认为，我们应当向前沿模型提供恰当的上下文和工具，然后让它决定应用程序的控制流。结果是高度单体化的设计：最终软件脆弱、消耗大量 Token、难以在组织范围内扩展，并且很少能够带来正向 ROI。

相反，我们应采用以行为为中心的方法：通过编码 harness 或 AI Agent 使用前沿智能，将我们的意图转化为可复用的行为。这些行为封装自身动作、拥有其生成的数据、能够轻松组合为工作流，并且仅在任务需要时调用前沿智能。由此产生的 Agentic 系统构建迅速、易于推理、可深度定制、拥有清晰的安全边界，并能够适应规模化带来的社会与技术挑战。

以 Agent 为中心的 AI 设计

以 Agent 为中心的设计理念，根植于现代 AI 时代最初的阶段，即 2022 年 11 月 ChatGPT 的发布。它使生成式 AI 成为通用聊天应用；到 2023 年 6 月，它已成为具备原生结构化函数调用能力的公共 API。其核心理念很简单：用户提出问题，LLM 通过推理决定从工具请求更多信息，将答案加入上下文，然后判断自己是否已有足够数据来组织答案。

Agent 循环（最简单形式）：LLM 决定是否调用工具，观察结果，并持续循环，直至能够生成最终答案。

1. 用户查询：“今天旧金山的天气怎么样？”
2. LLM（推理 + 工具使用）：接收用户消息，并可使用网页搜索、数据库查询、自定义函数等工具。
3. 工具调用：调用工具名称及其参数。
4. 工具结果：观察调用结果。
5. 是否完成？：由 LLM 决定。若否，将结果加入上下文并继续；若是，生成最终答案。
6. 最终答案：“旧金山气温为 68°F，天气晴朗。”

Agent 循环（最简单形式）：LLM 决定是否调用工具，观察结果，并持续循环，直至能够生成最终答案。

1. 用户查询：“今天旧金山的天气怎么样？”
2. LLM（推理 + 工具使用）：接收用户消息，并可使用网页搜索、数据库查询、自定义函数等工具。
3. 工具调用：调用工具名称及其参数。
4. 工具结果：观察调用结果。
5. 是否完成？：由 LLM 决定。若否，将结果加入上下文并继续；若是，生成最终答案。
6. 最终答案：“旧金山气温为 68°F，天气晴朗。”

LLM 是程序的核心，负责决定控制流（即程序下一步应做什么）。我们已尝试沿多个维度扩展这种方法：用于上下文搜索的 RAG、用于打包上下文和脚本的技能（skills）、用于让工具可插拔的 MCP、用于提供集中式安全能力的 MCP 网关、用于让 LLM 选择可插拔的模型路由器、用于并行化工作的子 Agent、多种 Agent 记忆方案、用于将这些内容整合在一起的 harness，等等。但无论行业加入什么，这一核心设计理念始终是这一切的中心。

这种设计的一个关键后果是单体 Agent。要执行复杂任务，正确的上下文、工具调用和模型推理必须全部组合到一起。如果继续在单个 Agent 边界内扩展 Agent 的能力，就会出现纵向扩展问题；我们会尝试通过工具搜索或代码模式等手段来解决它们。如果将 Agent 拆分成更小的部分，最终又会得到一个分布式单体：每个部分都与其他部分紧密耦合，但部署和可观测性表面积变得复杂得多。

旅行规划 Agent 示例

• 用户：“规划一次日本之旅”。
• 规划 Agent：拆解任务、调用子 Agent、聚合结果。
• 航班 Agent：接收“查找航班”请求，使用航班搜索工具获取实时数据，并返回航班选项。
• 酒店 Agent：接收“查找酒店”请求，使用预订工具搜索可订房源，并返回酒店选项。
• 规划 Agent：结合航班和酒店结果，进行推理并生成最终计划。
• 用户：“这是您的行程单！”

旅行规划 Agent 示例

• 用户：“规划一次日本之旅”。
• 规划 Agent：拆解任务、调用子 Agent、聚合结果。
• 航班 Agent：接收“查找航班”请求，使用航班搜索工具获取实时数据，并返回航班选项。
• 酒店 Agent：接收“查找酒店”请求，使用预订工具搜索可订房源，并返回酒店选项。
• 规划 Agent：结合航班和酒店结果，进行推理并生成最终计划。
• 用户：“这是您的行程单！”

无论做出何种权衡，只要由 LLM 负责控制流，得到的软件就会很脆弱。LLM 基于上下文——用户输入、系统提示词、技能、工具调用描述——以概率方式决定下一步做什么。例如，上图描述了一个旅行规划 Agent。用户期待行程始终包含酒店和航班，但规划 Agent 可能决定不调用酒店 Agent，导致最终输出不再符合用户预期；或者，它可能基于预算约束决定省略酒店。LLM 对控制流承担的责任越多，最终系统的正确性就越依赖于它在每个节点都做出正确决定——而这恰恰与 LLM 的本质相冲突。

为解决这种脆弱性，我们会通过增加返工和验证层来增强系统稳健性。例如，我们可能指示规划 Agent 始终仔细检查最终行程是否包含航班和酒店；如果缺少其中之一，就再次尝试调用底层酒店 Agent。我们甚至可能决定再增加一个 Agent，其唯一职责是验证规划 Agent 的结果；如果发现错误，就重新运行整个循环。

LLM 对控制流承担的责任越多，最终系统的正确性就越依赖于它在每个节点都做出正确决定——而这恰恰与 LLM 的本质相冲突。

这正是大规模运行复杂 Agentic 系统成本高昂的根源。每个新 Agent 都必须消耗 Token 来收集自己的上下文、推理下一步、将响应附加到自身上下文中，并推理如何响应。随后，这些 Agent 还需要更多 Agent 来验证整个系统没有悄然偏离用户预期。作为工程师，我们只能在成本效率、性能，以及对终端用户可见的瞬时故障韧性之间进行权衡。

这类脆弱系统有一个独特属性：对于设计它们的人而言，它们可能是可以接受的。当设计者要求 Agent 规划一次日本之旅时，他们知道系统是如何设计的，也明白它为什么有时决定不提供酒店。他们很容易忽略这一点——他们知道自己想要什么，知道为什么失败，也可以不断重试，直到获得正确结果。这只是一种“纸割伤”（papercut）：日常中一个小而恼人的瞬间。

但当我们通过增加更多具有不同预期的用户，或让系统承担越来越多职责，来将这些系统扩展到整个组织时，这些属性就变得不可接受。在社会层面，设想这是一个企业内部的旅行预订 Agent：终端用户将更难容忍不完整的行程单，尤其是在他们过度信任系统、最终出差却没有酒店可住时。在技术层面，为解决脆弱性而采取的方案需要不断扩大部署、可观测性和安全覆盖范围，使其在运营上越来越难以维护。

正是这种以 Agent 为中心的设计方法，导致许多 Agentic AI 系统无法展现正向 ROI：Gartner 预测，到 2027 年，超过 40% 的 Agentic AI 项目将被取消，而麦肯锡报告称，使用 AI 的企业中仅有 37% 能够证明其带来了任何财务影响。前沿智能能够解决企业中的大量问题，而且它确实做到了——例如，在个体生产力层面，它能够提升软件开发速度。但当我们从以 Agent 为中心的视角放大这些方法时，便会陷入死亡螺旋：为了使系统达到用户所要求、足以被接受的质量水平，其成本会急剧膨胀，摧毁我们最初采用它们的所有经济激励。

指标	数据来源	结论
到 2027 年将被取消的 Agentic AI 项目占比	Gartner	40%+
使用 AI 且能够证明存在财务影响的企业占比	McKinsey	37%

以行为为中心的 AI 设计

在以行为为中心的 Agent AI 设计中，我们专注于构建由可复用、可组合行为构成的语料库。每个行为都具有类型化、经过验证的输入和输出；生成符合版本化 Schema 的结构化数据，并自动建立搜索索引；同时拥有对凭据的独立隔离访问。平台会在运行时强制执行这些属性，而不是依赖约定或代码审查。最终得到的是一种构建模块：由于其契约得到保证，因此能够可靠组合，并且可由前沿智能维护。

以行为为中心的旅行规划架构

• 接口（Interfaces）：AI Agent、Harness、Chat、CLI、API、UI，可调用工作流或行为。
• 工作流（Workflows）：plan-trip。
  1. 提取请求：Haiku.extract()。
  2. 并行搜索航班和酒店：Flight.search()、Hotel.search()。
  3. 选择最佳选项：Itinerary.pick()。
  4. 生成行程：Itinerary.generate()。
• 行为（Behaviors）：Haiku 的 extract()、酒店搜索的 search()、航班搜索的 search()、行程的 pick() 与 generate()。
• 数据与凭据层：行为可读写数据、请求凭据，并使用结构化数据、产物（Artifacts）、搜索索引（Search Index）、Vault、Secrets 与 Credentials。

以行为为中心的旅行规划架构

• 接口（Interfaces）：AI Agent、Harness、Chat、CLI、API、UI，可调用工作流或行为。
• 工作流（Workflows）：plan-trip。
  1. 提取请求：Haiku.extract()。
  2. 并行搜索航班和酒店：Flight.search()、Hotel.search()。
  3. 选择最佳选项：Itinerary.pick()。
  4. 生成行程：Itinerary.generate()。
• 行为（Behaviors）：Haiku 的 extract()、酒店搜索的 search()、航班搜索的 search()、行程的 pick() 与 generate()。
• 数据与凭据层：行为可读写数据、请求凭据，并使用结构化数据、产物（Artifacts）、搜索索引（Search Index）、Vault、Secrets 与 Credentials。

上图展示了与此前相同的旅行规划 Agent，但它采用以行为为中心的方式构建。首先，我们将意图（“规划旅行”）拆分为一系列带有方法的行为：第一个行为调用 Anthropic 的 Haiku 5.5，从用户的初始提示中提取目的地城市、预算和日期。该行为将其发现作为结构化数据写入数据层，数据会在其中自动建立搜索索引。随后，酒店和航班行为会在指定日期范围内按城市搜索，并同样将结果存储为结构化数据。行程行为从选项列表中选择正确的航班和酒店，生成最终行程，并将其进度和最终结果保存为结构化数据。

随后，这些行为被组合为一个 plan-trip 工作流。该工作流按正确顺序调用相应方法，并使用存储为结构化数据的结果填充每个方法的参数。在这个例子中，只有第一步会调用前沿模型；在更复杂的工作流中，多个行为可能各自为需要智能能力的特定子任务调用 LLM。不同于以 Agent 为中心的设计，每次 LLM 调用都被限定在一个定义明确的单项任务中，绝不驱动更广泛系统的控制流。

要将这一行为变成 AI Agent，我们像之前一样，通过工具调用将其连接到 LLM。区别在于，现在我们已将交互表面积缩小为单次调用——通过工具、MCP 或 CLI 命令——把用户提示传入 plan-trip 工作流。该工作流调用正确的前沿模型、并行执行搜索、通过算法选出正确选项，并生成标准化行程。如果这是一个更复杂的 Agent，需要通过推理决定应选择哪些路径来解决问题，那么该推理将被封装在一个行为中：其输入是各个分支，其输出是所做的选择。

与以 Agent 为中心的设计不同，每次 LLM 调用都被限定在单个、定义明确的任务中，绝不驱动更广泛系统的控制流。

以 Agent 为中心设计中的脆弱性问题随之消失。行为中的每个方法都可以被直接调用，其参数在运行时具备类型约束并经过验证。它们生成的结构化数据必须符合已知且版本化的 Schema。控制流完全不消耗 Token；Token 仅用于使用廉价的前沿模型，将自由形式提示转化为结构化数据，或为 Agent 返回提示，以要求用户补充缺失信息。流程第一步之后不再需要验证步骤，因为其余部分都是普通的确定性代码。

扩展性问题也被消除。每位请求行程的用户都会收到一份行程，而且每次交付的结构一致。向系统添加更多功能不会影响系统的部署、可观测性或安全性——它只是新增了一个可从任何需要它的地方调用的行为；每个工作流、方法调用、数据访问或凭据使用，都可以借助 OpenTelemetry 等既有标准自动追踪。

Token 消耗显著降低。对于这个简单的旅行规划器，采用以行为为中心设计的实现使用的 Token 少了 14 倍，每份计划的成本低了 6 倍。节省来源很容易归因：以行为为中心的设计中，对前沿智能的唯一调用是提取旅行的初始约束；相比之下，以 Agent 为中心的设计需要将每一步结果重新传回 LLM，以编排下一项动作。当系统实现规模化时，不再存在 ROI 死亡螺旋——对一个用户有效的方法，也能以固定且可理解的成本服务整个企业。（原文至此截断）

Behavior-Centric AI Design

The industry is undergoing a fundamental shift in how it builds AI systems, from early experimentation to at-scale production use. The current agent-centric approach says that we should provide the right context and tooling to a frontier model, and then allow it to decide the control flow of our applications. It has resulted in highly monolithic designs, where the resulting software is fragile, token hungry, hard to scale across the organization, and rarely delivers a positive ROI.

Instead, we should adopt a behavior-centric approach that uses frontier intelligence through a coding harness or AI agent to translate our intent into reusable behaviors that encapsulate their actions, own the data they produce, compose easily into workflows, and call out to frontier intelligence only when the job requires it. The results are agentic systems that are rapid to build, easy to reason about, deeply customizable, have clear security boundaries, and adapt to the social and technological challenges of scale.

Agent-Centric AI Design

The agent-centric design philosophy has its roots at the very beginning of the modern AI era, with the release of ChatGPT in November of 2022. It made generative AI available as a general purpose chat application - by June of 2023, it was a public API with native, structured function calling. The core idea is simple - a user asks a question, and the LLM uses its reasoning to request more information from a tool, adds the answer to its context, and then decides if it has enough data to formulate the answer.

The Agent Loop (Simplest Form)An LLM decides whether to call a tool, observes the result, and continuesuntil it can produce a final answer.1. User Query“What's the weatherin SF today?”LLM(reasoning + tool use)User messageToolsWeb searchDatabase queryCustom function...2. Tool Call(name + arguments)3. Tool Result(observation)4. Done?(LLM decides)NoAdd result to contextand continueYes5. Final Answer“It's 68°F and sunny in San Francisco.”

The Agent Loop(Simplest Form)An LLM decides whether to call a tool, observes theresult, and continues until it can produce a finalanswer.1. User Query“What's the weather in SF today?”User messageLLM(reasoning + tool use)2. Tool Call(name + arguments)3. Tool Result(observation)ToolsWeb searchDatabase queryCustom function...4. Done?(LLM decides)NoAdd result to contextand continueYes5. Final Answer“It's 68°F and sunny inSan Francisco.”

The LLM is the heart of the program, making decisions about control flow (what the program should do next). We have tried to scale this approach across many vectors: RAG for contextual search, skills to bundle context and scripts, MCP for making tools pluggable, MCP gateways for providing centralized security, model routers to make the choice of LLM pluggable, sub-agents to parallelize work, multiple agent memory schemes, harnesses to bundle it all together, etc. But regardless of what the industry adds, this core design philosophy remains the heart of it all.

A key consequence of this design are monolithic agents. In order to perform complex tasks, the right combination of context, tool calls, and model reasoning all must combine. If we continue to expand the capabilities the agent has within a single agent boundary, we end up with vertical scalability problems - we try to resolve them with things like tool search or code mode. If we break the agent up into smaller pieces, we end up with a distributed monolith - each piece tightly coupled to the others, but with a much more complex deployment and observability surface area.

User“Plan a tripto Japan”query=“Plan a tripto Japan”Planner AgentBreaks down taskCalls sub-agentsAggregates resultsFlight AgentUses flight search toolsGets real-time dataReturns flight optionsHotel AgentUses booking toolsSearches availabilityReturns hotel optionsquery=“Find flights”query=“Find hotels”results=[flight options]results=[hotel options]Planner AgentCombines resultsApplies reasoningProduces final planUser“Here's youritinerary!”

User“Plan a trip to Japan”query=“Plan a trip to Japan”Planner AgentBreaks down taskCalls sub-agentsAggregates resultsquery=“Find flights”query=“Find hotels”Flight AgentUses flight search toolsGets real-time dataReturns flight optionsHotel AgentUses booking toolsSearches availabilityReturns hotel optionsresults=[flight options]results=[hotel options]Planner AgentCombines resultsApplies reasoningProduces final planUser“Here's your itinerary!”

No matter what trade-off you make, the LLM being responsible for control flow makes the resulting software fragile. The LLM decides what to do based on context - the user's input, system prompts, skills, tool call descriptions - and decides what to do probabilistically. For example, the above diagram describes a trip planning agent. The user’s expectation is that the itinerary always includes a hotel and a flight. The planning agent might decide not to call the hotel agent, causing the final output to no longer match the user’s expectations, or it might decide to omit the hotel based on budgetary constraints. The more an LLM is responsible for the control flow, the more the correctness of the resulting system relies on it making the right decision at every point - which cuts directly against the nature of the LLM.

To address this fragility, we make the system more robust by adding layers of rework and validation. For example, we might instruct the planning agent that it should always double check that the final itinerary has flights and a hotel, and if it is missing one, try the underlying hotel agent again. We might even decide to add yet another agent, whose only job is to validate the results of the planning agent, and run the entire loop again if it encounters an error.

“

The more an LLM is responsible for the control flow, the more the correctness of the resulting system relies on it making the right decision at every point - which cuts directly against the nature of the LLM.

This is the source of the dramatic cost of running complex agentic systems at scale. Each new agent has to spend tokens on gathering its own context, reasoning about its next steps, appending the responses to its own context, and reasoning about its response. Then those agents require even more agents to validate that the system as a whole didn’t subtly alter the user expectation. As an engineer, we are stuck making a tradeoff between systems that are cost efficient, performant, or resilient to transient failures we pass on to the end user.

A unique property of these fragile systems is that they can be acceptable to the person who designed them. When they ask their agent to plan a trip to Japan, they know how the system was designed, and why it sometimes decides not to give them a hotel. They can easily overlook it - they know what they wanted, they know why it failed, and they can just try again until they get it right. It’s a papercut - a small, annoying moment in their day.

When we scale these systems up in an organization by adding more users with different expectations, or have them take on more and more responsibilities, these properties become unacceptable. On a social level, imagine this was a booking agent for travel within the enterprise - suddenly the end users would be far less forgiving of an incomplete itinerary (especially if they trusted the system a little too much and wound up on a business trip without a hotel)! On a technical level, the solutions to the fragility require an ever widening deployment, observability, and security footprint - making them harder and harder to maintain operationally.

This agent-centric design approach is the reason why many agentic AI systems fail to show a positive ROI: Gartner predicts that over 40% of agentic AI projects will be cancelled by 2027, and McKinsey reports that only 37% of the enterprises using AI can show any financial impact. Frontier intelligence is capable of solving a huge number of problems across our businesses, and it does - at the level of individual productivity, for example, in software development velocity. But as we scale those approaches up through the agent-centric lens, we commit ourselves to a death spiral: to make the systems resilient enough to be acceptable at the level of quality users demand, the costs balloon out of control, destroying any economic incentive we had to adopt them.

of agentic AI projects will be cancelled by 2027 40%+ Gartner

of all enterprises using AI can show any financial impact 37% McKinsey

Behavior-Centric AI Design

In behavior-centric agent AI design, we focus on building a corpus of reusable, composable behaviors. Each behavior has typed, validated inputs and outputs; produces structured data that conforms to versioned schemas and is automatically indexed for search; and has its own isolated access to credentials. The platform enforces these properties at runtime rather than by convention or code review. The result is a building block that composes reliably because its contract is guaranteed, and can be maintained by frontier intelligence.

InterfacesAI AgentHarnessChatCLIAPIUICalls workflows or behaviorsWorkflowsplan-tripExtract requestHaiku.extract()Search flightsand hotels(in parallel)Flight.search()Hotel.search()Pick best optionItinerary.pick()Generate itineraryItinerary.generate()Calls behavior methodsBehaviorsHaikuextract()Hotel searchsearch()Flight searchsearch()Itinerarypick()generate()Read / write dataRequest credentialsDataStructured DataArtifactsSearch IndexVaultsSecrets &Credentials

InterfacesAI AgentHarnessChatCLIAPIUICalls workflows or behaviorsWorkflowsplan-tripExtract requestHaiku.extract()Search flightsand hotels(in parallel)Flight.search()Hotel.search()Pick best optionItinerary.pick()Generate itineraryItinerary.generate()Calls behavior methodsBehaviorsHaikuextract()Hotel searchsearch()Flight searchsearch()Itinerarypick()generate()Read / write dataRequest credentialsDataStructuredDataArtifactsSearchIndexVaultsSecrets &Credentials

The above diagram shows the same trip planning agent as before, but built in a behavior-centric way. We first decompose our intent (“plan trips”) into a series of behaviors with methods - the first one calling Anthropic’s Haiku 5.5 to extract the destination city, budget, and dates from the user's initial prompt. This behavior writes its findings as structured data to the data layer, where it is automatically indexed for search. Hotel and flight behaviors then search within cities for given dates, also storing their results as structured data. The itinerary behavior chooses the correct flights and hotels from a list of options and generates the final itinerary, storing its progress and the final results as structured data.

These behaviors then get composed together into a “plan-trip” workflow, which calls the correct methods in order, populating the arguments for each method from the results stored as structured data. In this example, only the first step calls a frontier model; in more complex workflows, multiple behaviors might each call an LLM for the specific subtask that requires intelligence. Unlike agent-centric design, each LLM call is scoped to a single, well-defined job and never drives the control flow of the broader system.

To turn this behavior into an AI agent, we connect it to an LLM with a tool call as before. The difference is that now we’ve reduced the surface area to a single call (via a tool, MCP, or as a CLI command) - passing the user’s prompt into the plan-trip workflow. The workflow calls out to the correct frontier model, searches in parallel, picks the right choices algorithmically, and generates a standardized itinerary. If this was a more complex agent that needed to apply reasoning to decide which pathways to take to solve a problem, that reasoning would be encapsulated in a behavior whose inputs are the branches, and the outputs are the choices.

“

Unlike agent-centric design, each LLM call is scoped to a single, well-defined job and never drives the control flow of the broader system.

The fragility issues with agent-centric design are gone. Each method on a behavior can be invoked directly, with its arguments typed and validated at runtime. They produce structured data that must conform to known, versioned schemas. No tokens are spent at all on control flow - only on using a cheap frontier model to transform a free-form prompt into structured data (or perhaps return a hint for the agent to ask the user to provide any missing information). There are no validation steps needed after the first step in the flow because everything else is regular old deterministic code.

The scaling issues are eliminated. Each user who requests an itinerary will receive one, delivered in the same shape every time. Adding more functionality to the system has no impact on the deployment, observability, or security of the system - it’s just one more behavior that can be invoked from anywhere that needs it, and each workflow, method invocation, data access, or credential used can be tracked automatically with existing standards like OpenTelemetry.

Token consumption is dramatically reduced. For our simple trip planner, an implementation using the behavior-centric design used 14x fewer tokens and costs 6x less per plan. The savings are easy to attribute - the only call to frontier intelligence in the behavior-centric design is extracting the initial constraints for the trip, versus passing the results of each step back into the LLM in order to orchestrate the next action. There is no longer an ROI death spiral as scale is encountered - what worked for one user works for the whole enterprise, at a fixed and understood cost.

fewer tokens with the behavior-centric design 14x Trip planner

cheaper per plan 6x Trip planner

The behavior-centric design also brings a unique benefit. Every behavior you create adds to a shared corpus of behaviors which can themselves be extended and reused in unique ways. When your DevOps team uses this pattern to manage infrastructure, the application development team can use those same behaviors to automate their application deployment process, and the SRE team can use them to help troubleshoot errors. By focusing on building repeatable, composable behaviors, you unlock the real value of enterprise-wide AI adoption.

Swamp is the proof

Swamp is a platform for building AI systems using the behavior-centric design pattern. It plugs into any coding harness and provides the skills and CLI tooling required for it to use frontier intelligence to translate your intent into a behavior-centric AI system. As an example, here was the prompt for the trip planner:

Build a workflow that plans trips using swamp. It should take a request like “plan a trip to japan”, extract the parameters of the trip (like when I leave, what city I’m going to), or fail with the missing parameters, then search hotels and flights, and pick the best option based on budget and comfort.

The harness then translated the prompt into the design above, built the search model for flights from scratch, reused an existing behavior for hotel search, and finalized the itinerary. It created all the behaviors, modeled the data, wrote the workflow, and tracked all the results. Instead of using frontier intelligence at runtime to decide what to do, we use it at build time to encode our intent into behaviors we can rely on.

Thousands of software developers have built production AI systems with Swamp, solving an incredible array of different problems. We’ve seen everything from software factories, infrastructure automation, and managing home labs to automating science lab experiments, controlling robot arms, sales lead scoring, and marketing management.

“

Instead of using frontier intelligence at runtime to decide what to do, we use it at build time to encode our intent into behaviors we can rely on.

The pattern delivers measurable results in production. Teams running code review workflows through Swamp have seen an 8x reduction in token costs and a 3x improvement in execution speed when compared to the agent-centric approach. Production SaaS services have been built and launched in days, with their entire team empowered to evolve them. Marketing teams use it for self-service campaign targeting, turning campaigns that would have taken days to build into minutes. Our own team’s software factory enables individual developers to ship hundreds of times a week, resolving reported bugs within an average of four hours.

Behavior-Centric AI Design works. It solves all of the problems that agent-centric design causes, creates a shared corpus of capabilities that compounds over time, and ultimately enables you to deliver on AI projects that can’t justify their ROI any other way.