a16z から見えたこと
enterprise pull は spreadsheet / financial workflow / legacy systems / computer use / long-horizon tasks に寄っている。 しかも reliable interfaces beyond text まで明示されている。つまり browser agent 自体より、 その下の digital work infra が厚くなる。
最新の web と X を当てると、harness / context engineering / MCP / shared state / eval / simulation はかなり見えてきた。 つまりそこを正面からやるのは遅い。今回の 3案は、2026 YC より一歩先で、 なおかつ computer use と long-horizon digital work が伸びる前提で、その一段下のレイヤーに寄せている。
enterprise pull は spreadsheet / financial workflow / legacy systems / computer use / long-horizon tasks に寄っている。 しかも reliable interfaces beyond text まで明示されている。つまり browser agent 自体より、 その下の digital work infra が厚くなる。
long-horizon agents の主戦場はすでに harness-based architectures, context engineering, traces, shared state にある。 ここは visible cluster。次に足りないのは、保存や orchestration ではなく world dynamics。
Polymath が simulated worlds、AgentHub が simulation and evaluation engine を明確に取っている。 だから pure eval / simulation company はもう funded category 側。
Managed Agents, context engineering, MCP, computer use はかなり飽和している。一方で world transition model は X でも direct hit がほぼない。MCP は syntax を標準化し始めたが、 effect semantics はまだ空いている。
browser, spreadsheet, SaaS, internal ops で agent が行動した時の before → action → after を巨大に集めるネットワーク。 汎用 browser trace ではなく、経済価値の高い digital work の遷移データに絞る。 最新の a16z シグナルに一番素直に乗れて、同時に最も独占しやすい。
今の市場は harness, eval, observability を作っているが、最終的に精度を分けるのは どの action が実際に何を起こしたか の corpus。そこはまだ誰も押さえていない。
a16z は enterprise value の出所として spreadsheet / financial workflow / computer use / long-horizon tasks を明示した。今まさに、価値の高い transition data が生まれ始めている。
generic browser trace company では弱い。 取るべきは digital work の中でも、価値と再現性がある workflow。具体的には spreadsheets, finance ops, legacy enterprise UI から始める。
表向きは failure replay / tool-effect analytics / regression debugging として導入する。裏では全部 transition data として貯める。顧客は debugging を買い、こちらは corpus を作る。
LangSmith, Langfuse, AgentHub, Polymath は trace / eval / simulation 側。彼らは valuable だが、市場全体の transition corpus を持つことを主目的にしていない。
Keiji 向きなのは model company ではなく data wedge company。最初の product は小さくてよく、データは使われるほど複利で強くなる。後発は UI を真似できても分布は真似できない。
search index と同じで、最も広くて深い transition corpus を持つ会社が、training, planning, eval, policy すべての上流に座れる。agent stack 全体の hidden dependency になれる。
current state + action → next state を予測する API。 ただし汎用世界モデルではなく、digital workflow world に限定する。 Sequoia が言うように traces と shared state は visible になった。だから次の本命は、 保存した state を使って何が起こるかを予測する層。
今の agent は shared state を持てても、その action の先に何が起きるか を十分に予測できない。だから long-horizon task で枝選択を外し、失敗を繰り返す。
Sequoia でも Anthropic でも、今の主戦場は harness, context engineering, traces。これは逆に言うと、その次の bottleneck が transition prediction だということ。
world model という言葉のままだと研究っぽすぎる。 売るべきは「agent の失敗を事前に減らす risk engine」。内部実装として transition model を持つ方が product になる。
最初は planning assistant ではなく、この action は高確率で失敗する / rollback が必要 を返す API として入る。buyer は reliability owner。そこから full prediction layer に伸ばす。
Polymath や AgentHub は simulation / eval、OpenAI や Anthropic は harness / shared state を強化している。だが digital workflow next-state prediction API を独立 product として握る会社はまだ薄い。
Keiji は robotics 正面より、browser + enterprise UI に寄せた software wedge の方が勝ちやすい。digital work に閉じれば、研究論文で終わらず実運用の reliability 層になれる。
もし主要 agent framework や enterprise agent stack の標準依存先になれば、payments API や search API のように、ほぼ全 agent call の前に入る。上流支配が効く。
MCP が標準化し始めたのは、主に どう呼ぶか という syntax。 でも agent が本当に困るのは、呼ぶと何が変わるか が分からないこと。 そこで作るのが、tool や UI action の precondition / postcondition / state delta / failure mode / permission boundary を machine-readable にする contract layer。
MCP や tool schema は 呼び出し方法 は教えてくれるが、効果 は教えてくれない。結果、planning, permissioning, rollback, verification が毎回 ad hoc になる。
a16z, OpenAI, Anthropic, Google, Vercel まで MCP を押し始めている。つまり syntax は急速にコモディティ化する。次の空白は effect semantics。
最初から「標準です」と言うのは弱い。 最初に売るべきは、tool overload を減らし、失敗を減らし、permission boundary を明確化する product。標準化は adoption の結果として起こす。
Anthropic が書くように agents には hundreds of tools がぶら下がる。そこで contract generator + runtime validator として入り、trace から effect semantics を学習して配布する。
MCP, OpenAPI, connectors はあるが、それは syntax / transport 側。effect contract を first-class に扱う主要勝者はまだ見えない。ここは post-MCP layer の勝負。
Keiji は protocol 団体を作るより、まず product から入るべき。generator, validator, policy engine を配れば distribution が取れ、その後に standard を押せる。
tool economy が拡大するほど、effect semantics を握るレイヤーは planning, security, observability, audit を跨ぐ control point になる。標準が取れれば winner-take-most が起きる。