Talk Session 2: AI Systems

From Agent Demos to Production: How Postman Is Building Reliable AI Agent Infrastructure

Rick Crawford — Field CTO, Postman(官網議程列為 Ankit Sobti, Co-Founder & CTO, Postman;現場為代講)

Sunday, August 2 · Compass Stage · 00:13:39–00:22:56 · afternoon stream

Postman used its own enterprise sales process as the testbed and found that a swarm of agents compounds both cost and confusion; the fix was to build one monolith agent that knows the whole domain and then layer a hallucination guard, domain personas, human-owned strategic content, and role-scoped authorization on top — with a help → recommend → act → own autonomy curve deciding how far the agent goes in each scenario.

TL;DR

  • The microservices lesson repeats itself with agents. The pile of specialized agents from their hackathon produced compounding cost and compounding confusion — the handoffs and testing between agents were the real problem. It was a decomposition problem, not something one more agent could fix.
  • The more deterministic the outcome, the more reliable the agent. Their win-loss agent could say "we lost this deal because our price was too high," and a human could reason backwards to check it. Ask the same agent how to generate leads and it went off the rails, producing output nobody could validate. Automate the questions whose answers can be verified in reverse.
  • Knowledge is not strategy. Asked which persona to sell to, the agent said "procurement" every single time — not technically wrong, but it would get you laughed out of the customer's room. Strategic content has to be supplied by the teams that own it: account plans from sales, solution plays from field engineering.

Key Points

Why enterprise sales, and the three problems the hackathon exposed (~00:13:39–00:17:45)

Postman already ran agent-first development, but wanted runtime agents that make decisions inside the business. Prototypes generated real excitement from the CEO and the board — and with it the harder questions: how do I measure this, manage this, and make sure what we ship stays maintainable? That is where ROI models and runbooks entered the picture.

They picked enterprise sales because the process is well defined (from identifying an opportunity to renewing the deal) yet spans many teams — and those teams struggle to hand off context to each other. Underneath sits a swarm of systems whose data relationships are hard to untangle. The net effect is an opaque process that leaks context at every step.

So they ran a hackathon (~00:15:52). In 30 hours engineers produced a mass of agents — drawn out, a tangle of systems, connections, and agents. The one that stood out was a win-loss agent, and from it came three core problems:

  1. The more deterministic the outcome, the better the agent performed (~00:16). The win-loss agent could explain why an account was lost, and a human could work backwards from that reasoning and sanity-check it. Ask it "what's the best way to generate leads?" and it drifted, producing results nobody could judge as right or wrong. Separately, a more complex model reasoned better — but understanding its results got correspondingly harder.
  2. It is a compounding problem (~00:17:13). Anyone who has built microservices recognizes the shape: A2A, agent communities, and then compounding cost plus compounding confusion, with handoffs and testing between agents becoming the dominant difficulty.
  3. It is a decomposition problem (~00:17:31). They kept building individual agents without noticing that all of them belonged to the same domain (he name-checked Martin Fowler here). The interfaces between the systems and the handoff of context were the real challenge.

The four-layer solution (~00:18:00–00:20:45)

Layer 1 — the monolith agent (~00:18:00). The foundation is a single agent that understands the whole sales process: Salesforce, Gong calls, transcripts. It answers genuinely interesting questions and makes a great co-pilot — but in gray areas it starts making things up, and as a generalist facing specialized questions it simply has too much information to give the right answer.

Layer 2 — decomposition, two pieces (~00:18:42). - A hallucination layer: don't recommend anything unless you clearly understand where the information came from; if you don't have it, explain why you reached that result. Output that can do neither is discarded. - Domain-specific agents, which are not a coding task at all — they are prompts ("I'm a seller, here's what I typically do") that make the agent answer in that persona. This sharpened output and killed most of the hallucination, but left it confidently wrong.

Layer 3 — humans own the strategy (~00:19:35). Knowledge and intelligence are not strategy. Asked which persona to sell to, the sales agent answered "procurement" every time; walking into a customer and announcing you're selling to their procurement organization would get you laughed out of the room. The fix was to identify the teams that own strategic content and put them in charge of contributing it — sales adding account plans, field engineering adding solution plays. Outputs became strategically relevant.

Layer 4 — role-scoped authorization (~00:20:20). At this point they had a super agent that understood the entire organization and no controls at all. Beyond "is this true?" they added "is this content related to the job that's requesting it?" — so the CTO agent won't hand over the company's P&L; it factors in your context and job role and returns only what is relevant to you.

The agent autonomy curve and compounding value (~00:20:50–00:22:56)

The autonomy curve asks, at each stage, whether the human or the agent makes the decision — and there are two decisions to separate: who requests the information, and who decides when to promote the result.

  • Help — the human does both: I ask the question, I analyze the result.
  • Recommend — the agent starts taking over part of it.
  • Actthe biggest step change: within guardrails, the agent does both sides of the equation.
  • Own — where everyone is heading: long-running agents that own the entire ecosystem.

The payoff surprised them. Building an agent went from a 30-hour hackathon to a matter of hours: with the framework in place, someone sets up guardrails and builds on the existing body of knowledge. Consumption spread from a select audience to the whole organization. Value compounded on both axes — development time and number of people benefiting.

There was also an unplanned behavioral shift: once salespeople understood that the context they create and the questions they ask feed the agents' underlying value, they did more discovery and produced better-quality content.

Finally, they turned the learnings into a platform: measure the outcomes, keep a catalog of available agents that teams can "hire and fire," and see each agent's real impact in both cost and return on investment (~00:22:42).

Quotes

"The more deterministic the outcome, the better the agent was." (~00:16:20)

Choosing the problem matters more than tuning the prompt: start where a human can verify the answer in reverse.

"Don't recommend something unless you have a clear understanding of where you're getting that information from." (~00:18:42)

The hallucination layer, specified in one sentence.

"It sharpened the output and it stopped doing a lot of the hallucinations, but it was confidently wrong. Knowledge and intelligence does not mean strategy." (~00:19:25)

Personas fixed hallucination but couldn't manufacture strategy — that stays a human-owned asset.

提到的專案與資源 / Projects & Resources

名稱 Name 說明 Description 備註 Notes
Win-loss agent Hackathon 產出中最有價值的 agent,解釋案子輸贏原因 The standout agent from the hackathon: explains why deals were won or lost 內部 agent / internal agent
Monolith agent 掌握整個銷售 domain 知識的地基 agent Foundation agent holding the whole sales domain's knowledge 內部 agent / internal agent
Hallucination layer 無明確來源就不建議、否則須解釋推理;兩者皆無則忽略輸出 Guard requiring a clear source, or an explanation of the reasoning; otherwise the output is ignored 內部機制 / internal mechanism
Agent autonomy curve help → recommend → act → own 四階段的自主度光譜 Four-stage autonomy spectrum: help → recommend → act → own 演講核心框架 / the talk's central framework
Salesforce / Gong Monolith agent 接入的資料來源(CRM 與通話錄音/逐字稿) Data sources feeding the monolith agent (CRM and call recordings/transcripts) 逐字稿 "Salesforce gone calls"
A2A 被點名為多 agent 通訊的代表,對應到微服務的複利問題 Cited as the agent-to-agent communication analogue of the microservices compounding problem
Martin Fowler(decomposition pattern) 用來說明「這是 decomposition 問題」的設計模式參照 Design-pattern reference used to frame the decomposition problem

逐字稿勘誤 / Transcript Corrections

字幕原文 Heard as 應為 Should be
Impostman in Postman
gone calls Gong calls
agents community agents agent-to-agent / agent communities
discreet discrete(講者當場改口為 deterministic)
rooting routing(此處為口誤脈絡,實際語意為 handoff)
longunning long-running

待確認 / To Verify

  • 講者身分:官網議程列 Ankit Sobti(Co-Founder & CTO),但主持人介紹的是 Rick Crawford(Field CTO),已查證 Rick Crawford 確為 Postman Field CTO。若協調者採「議程優先」原則,此檔需改名為 ankit-sobti--...。/ The agenda lists Ankit Sobti but the MC introduced Rick Crawford (verified as a Postman Field CTO). If the agenda-first rule is applied, rename this file to ankit-sobti--....
  • 演講最後提到的 Postman agent 平台產品名稱未在逐字稿中出現,需看投影片補上。/ The name of the Postman agent platform mentioned at the end never appears in the transcript; check the slides.
  • Autonomy curve 四階段的官方用詞:逐字稿為 "help / recommendations / act / own",正式命名待確認。/ The official wording of the four autonomy-curve stages.

Markdown source on GitHub ↗