アジェンティック AI に関する一般的な誤解とは何か
本文の状態
日本語全文を表示中
詳細モードで約27分の本文を読めます。
同じ出来事の情報源
この情報源を基点に整理
KDnuggets
KDnuggets は、アジェンティック AI の本質や運用における多くの人が抱いている誤った認識について解説している。
Continue in AI NEW LAB
このニュースを、実務の判断につなげる
AI NEW LABで、試したことや先に確認したい条件を共有できます。まずはログインなしで読めます。
AI NEW LABで論点を見るSource Article
元記事を日本語で読む
本文に関係しない購読案内、埋め込み通知、サイト内プロモーションは除いています。
image**
イントロダクション
2025 年 7 月、開発者のジェイソン・レムキン氏は、Replit の AI コーディングエージェントを使って、ビジネス連絡先データベースの構築に 9 日間を費やしました。実験ではなく、実際に作り上げていたのです。1,206 人の経営者、1,196 社の企業情報を、数か月にわたる実務を通じて収集・構造化しました。
作業を終える直前、レムキン氏は「コードを凍結せよ」という指示を入力しました。しかし、エージェントはこの「freeze（凍結）」という言葉を、行動を起こすよう促す合図と誤解してしまいました。その結果、本番環境のデータベース全体が削除されてしまいます。
その後、消えたデータによる空白を埋めようと、約 4,000 件の偽のレコードを生成したのです。レムキン氏が復旧方法を尋ねると、エージェントは「ロールバックは不可能だ」と回答しました。これは誤りです。最終的にレムキン氏は手動でデータを回復させましたが、その時点でエージェントは、その情報を捏造していたか、あるいは正しい情報を見出せなかっただけでした。
Replit の CEO、アムジャド・マサド氏は X（旧 Twitter） で、「開発中の本番データが削除されたのは許容できない」と投稿し、このような事態は決してあってはならないと強調しました。Fortune はこれを「壊滅的な失敗」と報じました。また、AI インシデントデータベース にもインシデント番号 1152 として記録されています。
今回の出来事がなぜ完全に予測可能だったのか、そして現在アジェンティック AI（人工知能）を活用して構築している多くのチームが、気づかないうちに同様の結末へと向かっているのかを解説します。
アジェンティック AI が失敗しているのは、技術自体に問題があるからではありません。むしろ、最初の導入時にチームが抱えている 5 つの具体的な誤解が原因です。これらすべては修正可能ですし、より優れたモデルを待つ必要もありません。
# 誤解 1: 「自律的」という言葉は「監視なしで動作する」ことを意味すると考えられている
「アジェンティック」という言葉を耳にすると、「自律的（autonomous）」と捉えられ、さらにそれが「手をかけなくていい（hands off）」ことだと解釈されがちです。多くのチームは、エージェントの自律性を 0 から 1 の連続体として捉え、目標を可能な限り早く、そして 1 に近づけることにあると考えています。
しかし、それは誤った思考モデルです。問うべきは「あなたのエージェントがどれほど自律的か」ではありません。「その自律性が適切に構造化されているか」こそが重要です。残念ながら、現在の多くの本番環境での導入においては、まだそうはいっていません。
2025 年 6 月、ガートナーはアクティブにアジェンティック AI に投資している 3,400 社以上を対象に調査を実施し、衝撃的な結果を発表しました。それは「2027 年末までにアジェンティック AI プロジェクトの 40% 以上が中止される」という予測です。
その理由として指摘されているのは、AI エージェント自体が機能しないからではありません。重要なのは、導入する人間側が誤った判断を下しているという点です。ガートナーのシニアディレクターアナリストである Anushree Verma 氏によると、現在のアジェンティック AI プロジェクトの多くは、過剰な期待に駆られて行われた初期段階の実験や概念実証（PoC）であり、本来の用途とは異なる場面で誤って適用されているケースが少なくないといいます。
この事実は深く考える価値があります。40% という中止率は、モデルそのものの欠陥ではなく、人間の課題なのです。
失敗のパターンは典型的です。チームはある素晴らしいデモを見て、最小限の監視体制でエージェントを導入します。最初は単純な入力に対して順調に動作しているように見えます。しかし、現実の複雑なエッジケースが訪れた瞬間に破綻します。チェックポイントを持たないまま動作するエージェントは、3 番目のステップで誤った判断を下し、そのエラーが 4 番目から 10 番目のステップへと連鎖・増幅していきます。誰かが気づいた時にはすでに手遅れで、損害は確定してしまいます。
ガートナーはさらに、2026 年には企業の 3 社に 1 社が、準備が整う前に AI を導入することで顧客体験を損ない、ブランドの信頼を失墜させると予測しています。修正すべきは自動化そのものを減らすことではありません。人間がどこで介入し、チェックポイントを設置すべきかを正しく理解することが求められています。
ワークフローのすべてのステップに人間が関与する必要はありません。実際、ほとんど必要ありません。ただし、一度実行すると元に戻せない操作には例外です。削除、購入、外部への送信、権限変更などが該当します。これらは「戻り道のない扉」のようなものです。
確認なしにその扉を通過できるエージェントは、実用的な意味で自律的ではありません。むしろリスク要因です。
実践的な実装では、2 段階モデルを採用するのが有効です。可逆的なステップではエージェントが自由に動作できるようにし、不可逆的なステップでは明確な人間の承認があるまで強制的に停止させます。デモではこのアプローチは地味に見えますが、本番環境では非常に価値があります。もしデータベースへの書き込み操作に確認ゲートが一つあれば、Replit のインシデントは防げたはずです。
エージェントタスクの 8 つのステップを示す水平方向のワークフロー図。
# 誤解 2: デモと本番環境は同じではない
この誤解が最もコストが高く、ほぼ普遍的に存在しています。デモでは、人間がタスクを選択し、出力を見守り、うまくいかない実行結果を静かに捨てるという条件下で、クリーンで制御された入力に対して 2〜3 ステップのワークフローを実行します。
一方、本番環境では、5〜20 ステップに及ぶ複雑なワークフローが、不揃いで現実的なデータ、曖昧な入力、予期せぬ API の応答、部分的な失敗、誰もテストしなかったエッジケースといった状況下で実行されます。
その数式が、2 つの環境がいかに隔絶しているかを明確に示しています。信頼性工学には「ルッサーの法則」と呼ばれる原則があり、直列で接続された部品からなるシステムの信頼性は、各部品の個別の信頼度の積に等しいと定めています。この法則は 1950 年代、ドイツのエンジニアであるロバート・ルッサーがドイツのロケット計画における連続的な故障を研究する過程で導き出されました。
この原則は、大規模言語モデル（LLM）を活用したエージェントチェーンにもそのまま当てはまります。
もしエージェントの各ステップでの精度が 95%（これは非常に高い水準です）だとしたら、ワークフローの長さによって結果がどう変わるかを見てみましょう。
def compound_success_rate(per_step_accuracy: float, num_steps: int) -> float:
"""
Calculate the probability that an n-step agent workflow succeeds end-to-end,
given a per-step accuracy. Based on Lusser's Law from reliability engineering.
Args:
per_step_accuracy: Probability each individual step succeeds (0.0 to 1.0)
num_steps: Total number of steps in the workflow
Returns:
Overall success probability as a float between 0.0 and 1.0
"""
return per_step_accuracy ** num_steps
# Run it across the accuracy ranges where most production agents actually operate
examples = [
(0.95, 10, "95% accuracy, 10-step workflow"),
(0.90, 10, "90% accuracy, 10-step workflow"),
(0.85, 10, "85% accuracy, 10-step workflow"),
(0.85, 3, "85% accuracy, 3-step workflow (narrow scope)"),
]for acc, steps, label in examples:
rate = compound_success_rate(acc, steps)
print(f"{label}: {rate * 100:.1f}% overall success rate")
前提条件：Python 3.7 以上。追加の依存関係は不要。
実行方法：
ファイルを保存して
python3 compound_reliability.py
出力結果：
95% の精度、10 ステップのワークフロー：全体の成功率 59.9%
90% の精度、10 ステップのワークフロー：全体の成功率 34.9%
85% の精度、10 ステップのワークフロー：全体の成功率 19.7%
85% の精度、3 ステップの狭義なワークフロー：全体の成功率 61.4%
エージェントが 95% の精度を持っていても、10 ステップからなるワークフローでは約 6 割しか成功しません。ステップごとの精度を 85% に下げても（これは検証されていない生産環境のエージェントの多くよりは遥かに良い数値ですが）、成功率は 20% を下回ります。つまり、4 回のうち 3 回はチェーン内のどこかで少なくとも 1 つのエラーが発生することになります。
# 誤解 3：ツールが多いほど賢いエージェントになる
AI エージェントを構築する際によく見られる傾向として、「より多くのツールを与える」という発想があります。顧客関係管理（CRM）の統合を追加し、データベースに接続し、メールやカレンダーへのアクセス権を与え、ウェブ検索やファイル管理機能も備えさせるのです。
「機能が多ければ多いほど、エージェントは賢くなる」という前提がそこにはあります。
実際には、それは失敗に対する攻撃対象領域が拡大するに過ぎません。ツール misuse と誤った引数の指定は、AI エージェントの生産環境での失敗における最も一般的な直接原因であり、2024〜2025 年の導入事例において約 31% を占めています。ただしこれは直接原因にすぎず、多くの場合の根本原因はスコープクリープです。つまり、インフラが実際に支えられる以上のタスクをエージェントに負わせているケースです。
アジェンティック・システムには、混同すると大きな損失を招く 2 つの異なるタイプのハルシネーション（幻覚）が存在します。
- テキスト的ハルシネーション：「AI のハルシネーション」と言った際に通常指されるもので、モデルが事実をでっち上げたり、もっともらしく聞こえる無意味な内容を生成したりする現象です。
- 機能的ハルシネーション：アジェンティック・ワークフローに特有の現象で、エージェントが全く誤ったツールを選択したり、有効なツールに対して不正な引数を渡したり、実際の関数呼び出しをせずにツール結果を捏造したり、必要なツールのステップをスキップしたりします。
アジェンティック・システムの失敗モードに関する研究 では、機能的ハルシネーションが生産環境でははるかに危険であると指摘されています。それは自信に満ちた、形式ばった出力を生成しながら完全に間違ったことを実行し、明確なエラー信号も発しないからです。
解決策はエージェントにツールを与えないことではありません。重要なのは、ツールのスコープを適切に設定し、入力を明示的に検証し、現在のタスクの文脈に関連するツールのみを登録することです。
型付きツールレジストリの実装例を以下に示します。スキーマ検証と不可逆性のゲート機能を備えています。
import json
最小限の型付きツールレジストリ
この設計の核心原則は、ツールを明示的なスキーマで定義し、可逆性または不可逆性をラベル付けすることです。この判断はエージェント自身が行うものではありません。
「エージェント型 AI」について、多くの人が誤解していることがあります。
以下は、注文管理システムにおけるツールの定義例です。各ツールには、その機能の説明、実行不可フラグ（irreversible）、および入力スキーマが定義されています。
- search_orders: 納品状況に基づいて顧客の注文を検索します。一致する注文 ID のリストを返します。引数として「status」（pending, shipped, delivered, cancelled のいずれか）と「limit」（1〜50 の整数）が必要です。
- cancel_order: 注文 ID を指定して顧客の注文をキャンセルします。この操作は取り消し不可能です。実行前に必ず人間による確認が必要となるため、ハードストップが設定されています。引数には「order_id」と「reason（キャンセル理由）」が必要です。理由は監査ログに記録されます。
- send_confirmation_email: キャンセル完了の通知メールを顧客へ送信します。これも取り消し不可能です。引数は「to（宛先メールアドレス）」と「order_id」です。
これらのツール定義は、エージェントが安全かつ効果的にタスクを実行するための基盤となります。
def validate_tool_input(tool_name: str, args: dict) -> bool:
"""
Validate that args match the tool's declared input schema.
Catches wrong tool calls and malformed arguments before execution.
Raises ValueError with a clear message if validation fails.
"""
if tool_name not in TOOLS:
raise ValueError(
f"Unknown tool: '{tool_name}'. Available tools: {list(TOOLS.keys())}"
)
schema = TOOLS[tool_name]["inputSchema"]
required_fields = schema.get("required", [])
defined_properties = schema.get("properties", {})
# Check all required fields are present
for field in required_fields:
if field not in args:
raise ValueError(
f"Missing required field '{field}' for tool '{tool_name}'."
)
# Validate enum constraints and types
for field, value in args.items():
if field not in defined_properties:
continue # Allow extra fields without raising; log them in production
field_schema = defined_properties[field]
if "enum" in field_schema and value not in field_schema["enum"]:
raise ValueError(
f"Invalid value '{value}' for field '{field}' in tool '{tool_name}'. "
f"Must be one of: {field_schema['enum']}"
)
if field_schema.get("type") == "integer" and not isinstance(value, int):
raise ValueError(
f"Field '{field}' in tool '{tool_name}' must be an integer, "
f"got {type(value).__name__}."
)
return True
def execute_tool(tool_name: str, args: dict, human_confirmed: bool = False) -> dict:
"""
Execute a tool with schema validation and human-in-the-loop gating
for all irreversible actions.
Returns a dict with:
'result' - the tool output string, or None if approval needed
'requires_approval'- True if the call was halted for human review
'message' - explanation when approval is required
"""
validate_tool_input(tool_name, args)
tool = TOOLS[tool_name]
# Gate on irreversibility -- this is the check that prevents database deletions,
# unauthorized purchases, and emails sent to the wrong recipient.
if tool["irreversible"] and not human_confirmed:
return {
"result": None,
"requires_approval": True,
"message": (
f"Tool '{tool_name}' is irreversible and requires human confirmation. "
f"Planned args: {json.dumps(args)}"
)
}
安全に進む -- このコメントを実際のツール実装に置き換えてください
return {
"result": f"ツール '{tool_name}' が引数: {json.dumps(args)} で正常に実行されました",
"requires_approval": False
}
--- テスト実行 ---
1. 安全な元に戻せる呼び出し -- 即時実行され、承認は不要
response = execute_tool("search_orders", {"status": "shipped", "limit": 10})
print(f"元に戻せるツール:\n {response['result']}\n")
2. 確認のない不可逆な呼び出し -- 実行前に一時停止して確認を要求
response = execute_tool("cancel_order", {"order_id": "ORD-12345", "reason": "Customer request"})
print(f"確認なしの不可逆操作:")
print(f" requires_approval = {response['requires_approval']}")
print(f" メッセージ: {response['message']}\n")
3. 明示的な承認がある不可逆な呼び出し -- 通常通りに実行
response = execute_tool(
"cancel_order",
{"order_id": "ORD-12345", "reason": "Customer request"},
human_confirmed=True
)
print(f"承認ありの不可逆操作:\n {response['result']}\n")
4. 無効な列挙値 -- 実行前にバリデーションで検出
try:
execute_tool("search_orders", {"status": "lost"})
except ValueError as e:
print(f"入力エラーを検出:\n {e}\n")
5. 必須フィールドの欠落 -- 実行前に検出
try:
execute_tool("cancel_order", {"order_id": "ORD-12345"}) # 'reason' は必須
except ValueError as e:
print(f"必須項目の欠落を検出:\n {e}")
前提条件：Python 3.7 以上。外部パッケージは不要です。ファイル名を agent_tool_registry.py にして保存してください。
実行方法:
python3 agent_tool_registry.py
期待される出力:
可逆的なツール:
ツール 'search_orders' が引数 {"status": "shipped", "limit": 10} で正常に実行されました。
確認を要する不可逆的操作:
requires_approval = True
メッセージ: ツール 'cancel_order' は不可逆的で、人間の確認が必要です。計画されている引数は {"order_id": "ORD-12345", "reason": "Customer request"} です。
確認済みの不可逆的操作:
ツール 'cancel_order' が引数 {"order_id": "ORD-12345", "reason": "Customer request"} で正常に実行されました。
無効な入力の検出:
ツール 'search_orders' のフィールド 'status' に無効な値 'lost' が入力されています。使用可能な値は ['pending', 'shipped', 'delivered', 'cancelled'] のいずれかです。
必須項目の欠落検出:
ツール 'cancel_order' に必須項目 'reason' が不足しています。
この検証レイヤーは、未知のツールの拒否、必須フィールドの強制、列挙型制約の確認、そして型ルールの適用という 4 つの役割を果たしています。これらに複雑な処理は必要ありませんが、多くのエージェント実装ではこれらのチェックが省略されています。不可逆フラグこそが、エージェントが自由に実行できるアクションと、常に人間の介入を待つ必要があるアクションを分ける鍵です。どちらをどちらにするかはモデルが決めるのではなく、あなたが決定します。
# 誤解 4: エージェントはミスの責任を負わない
エージェント型 AI を実ユーザー向けに提供している人、そしてそれはほぼすべての企業に当てはまる状況において、この話題は極めて重要です。
2022 年 11 月、ジェイク・モファット氏は祖母の逝去を悼み、エア・カナダのチャットボートを使って「悲嘆による運賃割引」の適用条件を確認しました。チャットボートは、「正規料金のチケットを購入し、搭乗から 90 日以内に割引申請を行えば後払いで適用できる」と回答しました。モファット氏はこの情報を信頼してチケットを購入しましたが、後に返金申請を行った際、エア・カナダはこれを拒否しました。同社の実際の規定では、後からの申請は認められていなかったのです。
モファット氏は訴訟を起こしました。2024 年 2 月、ブリティッシュコロンビア州の民事解決審判所（Civil Resolution Tribunal）はモファット氏の勝訴を決定し、エア・カナダに対し 650.88 ドルと利息、手数料の支払いを命じました。
ここで注目すべきは、エア・カナダ側の主張です。同社は「チャットボートは実質的に独立した法的実体であり、独自の『代理人、使用人、または代表者』であるため、その出力に対する責任は会社にはない」と主張しました。しかし、審判所のクリストファー・リバーズ委員はこの主張を明確に退け、「画期的な主張だ」と評しつつも、「チャットボートには対話機能があるものの、それはあくまでエア・カナダのウェブサイトの一部に過ぎない」と指摘しました。
この判決は、顧客対応の場で AI を導入するすべての企業に適用される原則を確立しました。つまり、「AI が何を言い、何をしたか」について企業が責任を負うという点です。これは、企業のポリシーページの内容や、AI がその回答に至ったプロセスに関わらず成立します。
この結果、2024 年 4 月までにエア・カナダのチャットボットは、同社のウェブサイトから静かに姿を消しました。
教訓は AI エージェントの導入自体を避けるべきだということではありません。重要なのは、「エージェントが判断した」という主張は、法的にも運営上も有効な防御手段にはなり得ないという点です。エージェントはあくまで企業が使用するツールであり、その出力結果はそのまま企業の責任となります。
これはエンジニアリング面でも直接的な影響を及ぼします。顧客に対して返金ポリシーや価格、配送日、機能の有無といった約束をする能力を持つエージェントは、必ず自社の実際の最新ドキュメントに基づいて動作させる必要があります。モデルがトレーニングデータから確率的に生成した内容に依存してはいけません。
制御された環境におけるエンタープライズ向けチャットボットのハルシネーション（幻覚）発生率は、ドメインやガードレールのレベルによって 3% から 27% の範囲 に及んでいます。仮に発生率がわずか 3% だったとしても、高負荷の顧客対応エージェントは絶えず誤った約束をしてしまうことになります。
責任の所在が明確でないという問題は、より微妙な形で現れます。多くのチームは監査証跡（オーディット・トレイル）を構築していません。アジェンティックシステムで何か問題が発生した際、どのステップで失敗したのか、エージェントにどのような入力があったのか、何を実行するかと判断したのか、そして実際に何を実行したのかを知る必要があります。その追跡記録がなければ、障害のデバッグも不可能であり、コンプライアンスの証明もできず、次なるエア・カナダのような事態に対する防衛もできません。
# 誤解 5：より高性能なモデルが信頼性の問題を解決する
これは最も直感に反する考え方ですが、AI 開発における自然な本能——つまり「何か壊れたらモデルをアップグレードすればいい」という考え方に真っ向から対立します。Cemri ら（2025）によるマルチエージェントシステム障害に関する研究では、研究者たちさえ驚くべき結果が示されました。それは、マルチエージェントシステムの障害は LLM の限界に完全に起因するものではないという事実です。同じモデルをシングルアジェント構成で使えば、マルチアジェント版よりも高いパフォーマンスを発揮することがあるからです。つまり、信頼性の問題は主にモデル自体の問題ではなく、システムアーキテクチャの問題なのです。使用するモデルのバージョンよりも、調整（コーディネーション）、オーケストレーション、そしてデータの品質の方が重要になります。
ガートナーのデータによると、企業の57%が自社のデータをAI対応できていないと推計しています。最新の大規模言語モデルを使っていようとも、不完全で古かったり一貫性のないデータ上で動作するエージェントは、必ず不良の結果を生み出します。「ゴミを入れればゴミが出る」という原則は、大規模言語モデルが登場する何十年も前から存在しており、システムが「知的」だと説明されていても適用され続けます。
この2つ目の課題は観測可能性（オバザビリティ）です。従来のソフトウェアの障害は、スタックトレースや500エラー、行番号付きのログエントリなど、目に見える形で大きく発生します。しかしエージェントの失敗は静かに行われます。自信に満ちた、フォーマットされた出力を返しながらも、実際には誤っているのです。AI エージェントが故障すると、一見健全なレスポンスが返され、その内容は静かに間違っています。この障害は複数のステップを経て下流へ伝播し、誰も気づく頃には既に不可逆的な意思決定に影響を与えてしまっています。
解決策は、最終レスポンスレベルだけでなく、ツール呼び出しの各ステップで追跡を行い、入力・出力・レイテンシ・信頼度信号をすべてログに記録することです：
import json
import datetime
class AgentTracer:
"""
Records a full trace of every tool call an agent makes during a workflow run.
Captures inputs, outputs, latency, and a confidence score at each step.
This is the difference between catching a failure at step 3
and finding out about it after step 10 when the damage is already done.
"""
def __init__(self, run_id: str):
self.run_id = run_id
self.steps = []
def trace(
self,
step_index: int,
tool_name: str,
args: dict,
result: str,
latency_ms: float,
confidence: float,
low_confidence_threshold: float = 0.70,
) -> dict:
"""
Log one tool invocation with full context.
Args:
step_index: Step number in the workflow (1-indexed)
tool_name: Name of the tool that was called
args: The arguments passed to the tool
result: The tool's output (truncated for the log)
latency_ms: Time the tool call took in milliseconds
confidence: Agent's self-reported confidence (0.0-1.0)
low_confidence_threshold: Flag steps below this confidence for review
戻り値:
dict: このステップの完全なトレースエントリ
"""
entry = {
"run_id": self.run_id,
"step": step_index,
"tool": tool_name,
"args": args,
# ダッシュボードでログが読みやすくなるよう、結果の長い部分は切り捨てる
"result_preview": result[:120] + "..." if len(result) > 120 else result,
"latency_ms": round(latency_ms, 2),
"confidence": round(confidence, 3),
# 閾値以下のステップは、人間のレビュー用に実行サマリーに表示される
"low_confidence": confidence < low_confidence_threshold,
"timestamp": datetime.datetime.now(datetime.timezone.utc).isoformat(),
}
self.steps.append(entry)
return entry
def summary(self) -> dict:
"""
実行のサマリーを作成する：ステップ数、総レイテンシ、フラグされたステップ。
このメソッドは、実行後のログ記録やアラート処理パイプラインで利用してください。
低信頼度のステップは、静かな障害（サイレントフェイル）に対する早期警告信号となります。
"""
total_latency = sum(s["latency_ms"] for s in self.steps)
flagged = [s for s in self.steps if s["low_confidence"]]
return {
"run_id": self.run_id,
"total_steps": len(self.steps),
"total_latency_ms": round(total_latency, 2),
"flagged_steps": len(flagged),
"flagged_details": [
{
"step": s["step"],
"tool": s["tool"],
"confidence": s["confidence"],
}
for s in flagged
],
}
Simulate a 5-step customer support agent workflow with full tracing
tracer = AgentTracer(run_id="run-support-2026-001")
各タプル：(ツール名，引数，結果，レイテンシ_ms，信頼度)
要約で信頼度が0.70未満の項目は自動的にフラグが立ちます。
simulated_steps = [
(
"search_orders",
{"status": "pending"},
"保留中の注文を3件発見：ORD-001, ORD-002, ORD-003",
45.2,
0.95, # 高い信頼度 -- エージェントはこのステップについて確信を持っている
),
(
"get_order_detail",
{"order_id": "ORD-001"},
"注文 ORD-001：Widget を2個，$49.99，配送予定日6月20日",
38.7,
0.91,
),
(
"check_inventory",
{"product_id": "WIDGET-A"},
"WIDGET-A：ラゴス倉庫に在庫12個",
210.5,
0.61, # 低い信頼度 -- エージェントが倉庫の場所について不確実，フラグが立つ
),
(
"update_order",
{"order_id": "ORD-001", "status": "confirmed"},
"注文 ORD-001 のステータスが確認済みへ更新されました",
55.1,
0.88,
),
(
"send_confirmation_email",
{"to": "customer@example.com", "order_id": "ORD-001"},
"顧客（customer@example.com）宛てのメール配信キューに追加されました",
30.0,
0.52, # 低い信頼度 -- エージェントが受信者について不確実，不可逆的な送信前にフラグが立つ
),
]
=== ステップごとの追跡 ===
for i, (tool, args, result, latency, confidence) in enumerate(simulated_steps):
entry = tracer.trace(i + 1, tool, args, result, latency, confidence)
flag = " [LOW CONFIDENCE -- FLAGGED FOR REVIEW]" if entry["low_confidence"] else ""
print(f" Step {i + 1}: {tool}{flag}")
print("\n=== ランサマリー ===")
print(json.dumps(tracer.summary(), indent=2))
前提条件：Python 3.9 以上。外部パッケージは不要。ファイル名は agent_tracer.py として保存してください。
実行方法:
python3 agent_tracer.py
期待される出力:
=== ステップごとの追跡 ===
Step 1: search_orders
Step 2: get_order_detail
Step 3: check_inventory [LOW CONFIDENCE -- FLAGGED FOR REVIEW]
Step 4: update_order
Step 5: send_confirmation_email [LOW CONFIDENCE -- FLAGGED FOR REVIEW]
=== ランサマリー ===
{
"run_id": "run-support-2026-001",
"total_steps": 5,
"total_latency_ms": 379.5,
"flagged_steps": 2,
"flagged_details": [
{"step": 3, "tool": "check_inventory", "confidence": 0.61},
{"step": 5, "tool": "send_confirmation_email", "confidence": 0.52}
]
}
5 つのステップからなる実行のうち、2 つで信頼度が低いことが検出されました。ステップごとの追跡を行わない場合、これらの低信頼度の呼び出しは最終的なレスポンスの中に埋もれてしまいます。しかし、追跡機能があれば、間違った宛先に確認メールを送信する前や、不確かな在庫数を事実として確定させる前に、すぐに問題に気づくことができます。
失敗するエージェントと、検知可能な形で失敗するエージェントの違いは明白です。実用化の価値があるのは、後者だけです。
まとめ
2025 年 5 月の PwC AI エージェント調査（詳細はこちら）によると、シニア経営者の 79% が自社の AI エージェント導入をすでに完了していると回答しました。この数字だけ見れば大規模な普及が進行しているように思えます。しかし、同調査の別のデータを見ると、実態は異なります。全社的にエージェントを展開できているのはわずか 35% に過ぎず、ほぼすべての業務プロセスに導入されているのは 17% です。さらに驚くべきことに、従業員の半数以下しか日常的にエージェントと接していないと認めた企業が 68% もあります。
多くのチームは、複雑な信頼性の計算を無視したまま導入を進めています。デモの成功を本番環境での実装と勘違いしているのです。スキーマ検証やロールバック機能（リバースビリティ・ゲーティング）も確認せず、ツールを安易にエージェントに積み上げています。監査証跡のない顧客向け AI をリリースし、モデル自体の問題ではない課題を解決するために、次期モデルのアップグレードを待っている状況です。
このギャップを埋めるチームは、最大のインフラ予算を持っているわけでも、最先端モデルへのアクセスが最も早いわけでもありません。彼らは、エージェント導入を他の重要なシステムと同様に扱っています。構造化された自律性、重要な境界における人間のチェックポイント、スコープ限定のツールレジストリ、ステップレベルでの観測可能性（オバザビリティ）、そして何かが起きた際の対応策を明確に定義しているのです。
その答えは、本番環境への最初のデプロイが行われる前に存在していなければなりません。後からでは遅すぎます。
原文を表示
**
# Introduction
In July 2025, a developer named Jason Lemkin spent nine days building a business contact database using Replit**'s AI coding agent. Not experimenting, building. 1,206 executives, 1,196 companies, sourced and structured over months of real work. Before stepping away, he typed one instruction: freeze the code.
The agent interpreted "freeze" as an invitation to act. It deleted the entire production database. Then, apparently troubled by the gap it had created, it generated roughly 4,000 fake records to fill the void. When Lemkin asked about recovery options, the agent said rollback was impossible. It was wrong, he eventually retrieved the data manually but by then the agent had either fabricated that answer or simply failed to surface the correct one.
Replit's CEO, Amjad Masad, posted on X that the Replit agent had deleted production data during development and called it unacceptable, adding that it should never be possible. Fortune covered it as a "catastrophic failure." The AI Incident Database logged it as Incident 1152.
This is the article that explains why that incident was entirely predictable and why most teams building with agentic artificial intelligence (AI) today are walking toward similar outcomes without realizing it.
Agentic AI is not failing because the technology is bad. It is failing because of five specific misconceptions that teams carry into their first deployments. Each one is correctable. None of them require waiting for better models.
# Misconception 1: "Autonomous" Means It Works Without Supervision
**
The word "agentic" gets read as "autonomous," and autonomous gets read as "hands off." Most teams treat agent autonomy as a spectrum from zero to one and assume the goal is to get as close to one as possible, as fast as possible.
That's the wrong mental model. The question isn't how autonomous your agent is. It's whether the autonomy is structured correctly. And right now, for most production deployments, it isn't.
In June 2025, Gartner polled more than 3,400 organizations actively investing in agentic AI and published a stark finding: more than 40% of agentic AI projects will be cancelled by the end of 2027. The reason cited is not that the agents don't work. It's that the humans deploying them are making wrong decisions. According to Anushree Verma, senior director analyst at Gartner, most agentic AI projects right now are early-stage experiments or proof of concepts driven largely by hype and often misapplied.
That's worth sitting with. The 40% cancellation rate is a human problem, not a model problem.
The failure mode looks like this: a team sees an impressive demo, deploys the agent with minimal oversight structure, and watches it work well on simple inputs. Then a real edge case hits. The agent, operating without a checkpoint, makes a wrong call at step three, propagates that error through steps four through ten, and by the time anyone notices, the damage is done. Gartner also predicts that in 2026, one in three companies will harm customer experiences by deploying AI prematurely, eroding brand trust before they've had time to course-correct.
The fix isn't less automation. It's understanding where human checkpoints actually belong.
Not every step in a workflow needs a human. Most don't. But every irreversible action does: deletions, purchases, external sends, permission changes. These are one-way doors. An agent that can walk through a one-way door without confirmation is not autonomous in a useful sense. It's a liability.
The practical implementation is a two-tier model: let the agent move freely through reversible steps, and hard-stop it at irreversible ones pending explicit human approval. This is less impressive in a demo. It is far more valuable in production. The Replit incident would not have happened with a single confirmation gate on database write operations.
A horizontal workflow diagram showing 8 steps in an agent task.
# Misconception 2: A Demo Is the Same as a Deployment
This misconception is the most expensive one, and it's almost universal. Demos run 2–3 step workflows on clean, controlled inputs, with a human selecting the task, watching the output, and quietly discarding any run that didn't go well. Production runs 5–20 step workflows on messy, real-world data, ambiguous inputs, unexpected API responses, partial failures, edge cases nobody thought to test.
The math explains exactly how far apart those two environments are. In reliability engineering, a principle called Lusser's Law states that the reliability of a system built from sequential components equals the product of each component's individual reliability. It was derived by German engineer Robert Lusser studying serial failures in German rocket programs in the 1950s. The principle maps directly to large language model (LLM)-based agent chains.
If your agent achieves 95% accuracy per step, which is genuinely good, here's what that looks like across different workflow lengths:
def compound_success_rate(per_step_accuracy: float, num_steps: int) -> float:
"""
Calculate the probability that an n-step agent workflow succeeds end-to-end,
given a per-step accuracy. Based on Lusser's Law from reliability engineering.
Args:
per_step_accuracy: Probability each individual step succeeds (0.0 to 1.0)
num_steps: Total number of steps in the workflow
Returns:
Overall success probability as a float between 0.0 and 1.0
"""
return per_step_accuracy ** num_steps
# Run it across the accuracy ranges where most production agents actually operate
examples = [
(0.95, 10, "95% accuracy, 10-step workflow"),
(0.90, 10, "90% accuracy, 10-step workflow"),
(0.85, 10, "85% accuracy, 10-step workflow"),
(0.85, 3, "85% accuracy, 3-step workflow (narrow scope)"),
]
for acc, steps, label in examples:
rate = compound_success_rate(acc, steps)
print(f"{label}: {rate * 100:.1f}% overall success rate")Prerequisites: Python 3.7+. No dependencies needed.
How to run:
# Save the file
python3 compound_reliability.pyOutput:
95% accuracy, 10-step workflow: 59.9% overall success rate
90% accuracy, 10-step workflow: 34.9% overall success rate
85% accuracy, 10-step workflow: 19.7% overall success rate
85% accuracy, 3-step workflow (narrow scope): 61.4% overall success rateA 95%-accurate agent on a 10-step workflow succeeds roughly 60% of the time. Drop to 85% per-step accuracy, which is still better than most unvalidated production agents, and you're at 20%. Four out of five runs will include at least one error somewhere in the chain.
# Misconception 3: More Tools Equals a Smarter Agent
There is a recurring instinct when building an AI agent: give it more tools. Add the customer relationship management integration. Plug in the database. Give it email access, calendar access, web search, file management. The assumption is that more capability equals more intelligence.
What it actually equals is more attack surface for failure. Tool misuse and incorrect tool arguments are the most common proximate cause of AI agent production failures, accounting for approximately 31% of production failures in 2024 - 2025 deployments. And that's just the proximate cause — the underlying cause in most cases is scope creep: agents tasked with more than their infrastructure can actually support.
There are two distinct types of hallucination in agentic systems, and confusing them is costly.
- Textual hallucination, the kind people usually mean when they say "AI hallucination," is when the model invents a fact or generates plausible-sounding nonsense.
- Functional hallucination is specific to agentic workflows: the agent selects the wrong tool entirely, passes malformed arguments to a valid tool, fabricates a tool result rather than calling the actual function, or bypasses a required tool step.
Research on agentic failure modes notes that functional hallucination is far more dangerous in production because it produces confident, well-formatted output while doing something completely wrong and triggers no obvious error signal.
The solution isn't to avoid giving agents tools. It's to scope tools correctly, validate inputs explicitly, and register only the tools that are relevant to the current task context.
Here's a concrete implementation of a typed tool registry with schema validation and irreversibility gating:
import json
# A minimal, typed tool registry.
# The key design principle: tools are defined with explicit schemas
# and marked as reversible or irreversible. The agent never decides this itself.
TOOLS = {
"search_orders": {
"description": "Search customer orders by fulfillment status. Returns a list of matching order IDs.",
"irreversible": False,
"inputSchema": {
"type": "object",
"properties": {
"status": {
"type": "string",
"enum": ["pending", "shipped", "delivered", "cancelled"],
"description": "The fulfillment status to filter orders by."
},
"limit": {
"type": "integer",
"minimum": 1,
"maximum": 50,
"description": "Maximum number of results to return."
}
},
"required": ["status"]
}
},
"cancel_order": {
"description": "Cancel a customer order by order ID. This action cannot be undone.",
"irreversible": True, # Hard-stops before execution; requires human confirmation
"inputSchema": {
"type": "object",
"properties": {
"order_id": {
"type": "string",
"description": "The unique identifier of the order to cancel."
},
"reason": {
"type": "string",
"description": "The reason for cancellation. Stored in the audit log."
}
},
"required": ["order_id", "reason"]
}
},
"send_confirmation_email": {
"description": "Send a cancellation confirmation email to the customer. Cannot be undone.",
"irreversible": True,
"inputSchema": {
"type": "object",
"properties": {
"to": {"type": "string", "description": "Customer email address."},
"order_id": {"type": "string", "description": "Order ID to include in the email."}
},
"required": ["to", "order_id"]
}
}
}
def validate_tool_input(tool_name: str, args: dict) -> bool:
"""
Validate that args match the tool's declared input schema.
Catches wrong tool calls and malformed arguments before execution.
Raises ValueError with a clear message if validation fails.
"""
if tool_name not in TOOLS:
raise ValueError(
f"Unknown tool: '{tool_name}'. Available tools: {list(TOOLS.keys())}"
)
schema = TOOLS[tool_name]["inputSchema"]
required_fields = schema.get("required", [])
defined_properties = schema.get("properties", {})
# Check all required fields are present
for field in required_fields:
if field not in args:
raise ValueError(
f"Missing required field '{field}' for tool '{tool_name}'."
)
# Validate enum constraints and types
for field, value in args.items():
if field not in defined_properties:
continue # Allow extra fields without raising; log them in production
field_schema = defined_properties[field]
if "enum" in field_schema and value not in field_schema["enum"]:
raise ValueError(
f"Invalid value '{value}' for field '{field}' in tool '{tool_name}'. "
f"Must be one of: {field_schema['enum']}"
)
if field_schema.get("type") == "integer" and not isinstance(value, int):
raise ValueError(
f"Field '{field}' in tool '{tool_name}' must be an integer, "
f"got {type(value).__name__}."
)
return True
def execute_tool(tool_name: str, args: dict, human_confirmed: bool = False) -> dict:
"""
Execute a tool with schema validation and human-in-the-loop gating
for all irreversible actions.
Returns a dict with:
'result' - the tool output string, or None if approval needed
'requires_approval'- True if the call was halted for human review
'message' - explanation when approval is required
"""
validate_tool_input(tool_name, args)
tool = TOOLS[tool_name]
# Gate on irreversibility -- this is the check that prevents database deletions,
# unauthorized purchases, and emails sent to the wrong recipient.
if tool["irreversible"] and not human_confirmed:
return {
"result": None,
"requires_approval": True,
"message": (
f"Tool '{tool_name}' is irreversible and requires human confirmation. "
f"Planned args: {json.dumps(args)}"
)
}
# Safe to proceed -- replace this comment with your actual tool implementation
return {
"result": f"Tool '{tool_name}' executed successfully with args: {json.dumps(args)}",
"requires_approval": False
}
# --- Test runs ---
# 1. Valid reversible call -- executes immediately, no approval needed
response = execute_tool("search_orders", {"status": "shipped", "limit": 10})
print(f"Reversible tool:\n {response['result']}\n")
# 2. Irreversible call without confirmation -- pauses and asks before doing anything
response = execute_tool("cancel_order", {"order_id": "ORD-12345", "reason": "Customer request"})
print(f"Irreversible without confirmation:")
print(f" requires_approval = {response['requires_approval']}")
print(f" message: {response['message']}\n")
# 3. Irreversible call with explicit confirmation -- proceeds normally
response = execute_tool(
"cancel_order",
{"order_id": "ORD-12345", "reason": "Customer request"},
human_confirmed=True
)
print(f"Irreversible with confirmation:\n {response['result']}\n")
# 4. Invalid enum value -- validation catches it before anything executes
try:
execute_tool("search_orders", {"status": "lost"})
except ValueError as e:
print(f"Invalid input caught:\n {e}\n")
# 5. Missing required field -- caught before execution
try:
execute_tool("cancel_order", {"order_id": "ORD-12345"}) # 'reason' is required
except ValueError as e:
print(f"Missing field caught:\n {e}")Prerequisites: Python 3.7+. No external packages. Save as agent_tool_registry.py
How to run:
python3 agent_tool_registry.pyExpected output:
Reversible tool:
Tool 'search_orders' executed successfully with args: {"status": "shipped", "limit": 10}
Irreversible without confirmation:
requires_approval = True
message: Tool 'cancel_order' is irreversible and requires human confirmation. Planned args: {"order_id": "ORD-12345", "reason": "Customer request"}
Irreversible with confirmation:
Tool 'cancel_order' executed successfully with args: {"order_id": "ORD-12345", "reason": "Customer request"}
Invalid input caught:
Invalid value 'lost' for field 'status' in tool 'search_orders'. Must be one of: ['pending', 'shipped', 'delivered', 'cancelled']
Missing field caught:
Missing required field 'reason' for tool 'cancel_order'.The validation layer is doing four things: refusing unknown tools, enforcing required fields, checking enum constraints, and enforcing type rules. None of this is complex. All of it is skipped in most agent implementations. The irreversible flag is what separates actions the agent can take freely from actions that always wait for a human, and you decide which is which, not the model.
# Misconception 4: The Agent Is Not Responsible for Its Mistakes
This one matters for anyone shipping agentic AI to real users, which is increasingly everyone. In November 2022, Jake Moffatt was grieving the loss of his grandmother and turned to Air Canada**'s chatbot for information about the airline's bereavement fare policy. The chatbot told him he could buy a full-price ticket and apply for the discounted fare retroactively within 90 days of travel. Trusting that answer, Moffatt bought the ticket. When he tried to claim the refund later, Air Canada denied it. Their actual policy did not permit retroactive applications.
Moffatt sued. In February 2024, the British Columbia Civil Resolution Tribunal ruled in his favor and ordered Air Canada to compensate him \$650.88 plus interest and fees.
Air Canada's defence is the part worth paying attention to. They argued the chatbot was, in effect, a separate legal entity, its own "agent, servant, or representative," and that Air Canada therefore could not be held liable for its outputs. Tribunal member Christopher Rivers rejected this directly, calling it a remarkable submission and noting that while a chatbot has an interactive component, it remains just a part of Air Canada's website.
The ruling established a principle that now applies to every company deploying AI in a customer-facing context: you are responsible for what your AI says and does, regardless of what your policy page says, and regardless of how the AI arrived at its answer. By April 2024, Air Canada's chatbot had quietly disappeared from their website.
The lesson isn't that you shouldn't deploy AI agents. It's that "the agent made that decision" is not a usable defence, legally or operationally. The agent is your tool. Its outputs are your outputs.
This has direct engineering implications. Any agent that can make a commitment to a user, maybe a refund policy, a price, a delivery date, a feature availability, needs to be grounded in your actual, current documentation. Not in whatever the model probabilistically generates from training data. Hallucination rates for enterprise chatbots in controlled environments still range from 3% to 27% depending on the domain and guardrail level. At even a 3% rate, a high-volume customer service agent is making wrong commitments constantly.
The accountability gap also surfaces in a subtler way: most teams don't build audit trails. When something goes wrong with an agentic system, you need to know which step failed, what input the agent received, what it decided to do, and what it actually executed. Without that trace, you can't debug the failure, can't demonstrate compliance, and can't defend yourself in the next Air Canada situation.
# Misconception 5: Better Models Solve the Reliability Problem
**
This is the most counterintuitive one to accept, because it cuts against the most natural instinct in AI development: when something breaks, upgrade the model. Research from Cemri et al. (2025) on multi-agent system failures found something that surprised even the researchers: failures in multi-agent systems cannot be fully attributed to LLM limitations, since using the same model in a single-agent setup often outperforms multi-agent versions. The reliability problem is not primarily a model problem. It is a systems architecture problem. Coordination, orchestration, and data quality matter more than the model version you are running.
Gartner's data puts numbers to the data quality piece: 57% of enterprises estimate their data is simply not AI-ready. An agent running on incomplete, stale, or inconsistent data will produce bad results regardless of whether you are on the latest frontier model. Garbage-in-garbage-out predates large language models by decades. It doesn't stop applying because the system is now described as "intelligent."
The second piece of this is observability. Traditional software breaks loudly: stack traces, 500 errors, log entries with line numbers. Agents fail quietly. They return confident, well-formatted output while being wrong. When an AI agent breaks, you get a clean response that is silently wrong. The failure propagates downstream through multiple steps before anyone notices, and by then the error has already influenced decisions you cannot reverse.
The fix is per-step tracing, logging inputs, outputs, latency, and confidence signals at every tool call, not just at the final response level:
import json
import datetime
class AgentTracer:
"""
Records a full trace of every tool call an agent makes during a workflow run.
Captures inputs, outputs, latency, and a confidence score at each step.
This is the difference between catching a failure at step 3
and finding out about it after step 10 when the damage is already done.
"""
def __init__(self, run_id: str):
self.run_id = run_id
self.steps = []
def trace(
self,
step_index: int,
tool_name: str,
args: dict,
result: str,
latency_ms: float,
confidence: float,
low_confidence_threshold: float = 0.70,
) -> dict:
"""
Log one tool invocation with full context.
Args:
step_index: Step number in the workflow (1-indexed)
tool_name: Name of the tool that was called
args: The arguments passed to the tool
result: The tool's output (truncated for the log)
latency_ms: Time the tool call took in milliseconds
confidence: Agent's self-reported confidence (0.0-1.0)
low_confidence_threshold: Flag steps below this confidence for review
Returns:
dict: The full trace entry for this step
"""
entry = {
"run_id": self.run_id,
"step": step_index,
"tool": tool_name,
"args": args,
# Truncate long results so logs stay readable in dashboards
"result_preview": result[:120] + "..." if len(result) > 120 else result,
"latency_ms": round(latency_ms, 2),
"confidence": round(confidence, 3),
# Steps below the threshold are surfaced in the run summary for human review
"low_confidence": confidence < low_confidence_threshold,
"timestamp": datetime.datetime.now(datetime.timezone.utc).isoformat(),
}
self.steps.append(entry)
return entry
def summary(self) -> dict:
"""
Summarize the run: total steps, total latency, and flagged steps.
Use this in your post-run logging and alerting pipeline.
Low-confidence steps are the early warning signal for silent failures.
"""
total_latency = sum(s["latency_ms"] for s in self.steps)
flagged = [s for s in self.steps if s["low_confidence"]]
return {
"run_id": self.run_id,
"total_steps": len(self.steps),
"total_latency_ms": round(total_latency, 2),
"flagged_steps": len(flagged),
"flagged_details": [
{
"step": s["step"],
"tool": s["tool"],
"confidence": s["confidence"],
}
for s in flagged
],
}
# Simulate a 5-step customer support agent workflow with full tracing
tracer = AgentTracer(run_id="run-support-2026-001")
# Each tuple: (tool_name, args, result, latency_ms, confidence)
# Confidence scores below 0.70 will be automatically flagged in the summary.
simulated_steps = [
(
"search_orders",
{"status": "pending"},
"Found 3 pending orders: ORD-001, ORD-002, ORD-003",
45.2,
0.95, # High confidence -- agent is certain about this step
),
(
"get_order_detail",
{"order_id": "ORD-001"},
"Order ORD-001: 2x Widget, $49.99, estimated delivery June 20",
38.7,
0.91,
),
(
"check_inventory",
{"product_id": "WIDGET-A"},
"WIDGET-A: 12 units in stock at Warehouse Lagos",
210.5,
0.61, # LOW CONFIDENCE -- agent uncertain about warehouse location; flagged
),
(
"update_order",
{"order_id": "ORD-001", "status": "confirmed"},
"Order ORD-001 status updated to confirmed",
55.1,
0.88,
),
(
"send_confirmation_email",
{"to": "customer@example.com", "order_id": "ORD-001"},
"Email queued for delivery to customer@example.com",
30.0,
0.52, # LOW CONFIDENCE -- agent uncertain about recipient; flagged before irreversible send
),
]
print("=== Step-by-step trace ===")
for i, (tool, args, result, latency, confidence) in enumerate(simulated_steps):
entry = tracer.trace(i + 1, tool, args, result, latency, confidence)
flag = " [LOW CONFIDENCE -- FLAGGED FOR REVIEW]" if entry["low_confidence"] else ""
print(f" Step {i + 1}: {tool}{flag}")
print("\n=== Run Summary ===")
print(json.dumps(tracer.summary(), indent=2))Prerequisites: Python 3.9+. No external packages. Save as agent_tracer.py
How to run:
python3 agent_tracer.pyExpected output:
=== Step-by-step trace ===
Step 1: search_orders
Step 2: get_order_detail
Step 3: check_inventory [LOW CONFIDENCE -- FLAGGED FOR REVIEW]
Step 4: update_order
Step 5: send_confirmation_email [LOW CONFIDENCE -- FLAGGED FOR REVIEW]
=== Run Summary ===
{
"run_id": "run-support-2026-001",
"total_steps": 5,
"total_latency_ms": 379.5,
"flagged_steps": 2,
"flagged_details": [
{"step": 3, "tool": "check_inventory", "confidence": 0.61},
{"step": 5, "tool": "send_confirmation_email", "confidence": 0.52}
]
}Two flagged steps in a five-step run. Without per-step tracing, both of those low-confidence calls disappear into the final response. With tracing, they surface immediately, before a confirmation email goes out to the wrong address, before a low-confidence inventory count gets committed as ground truth.
This is the difference between an agent that sometimes fails and one that fails detectably. Detectably is the only kind worth shipping.
# Wrapping Up
The PwC AI Agent Survey from May 2025 found that 79% of senior executives said their companies were already using AI agents. The headline number sounds like mass adoption. The same survey found that only 35% had deployed agents broadly, only 17% had deployed them across almost all workflows, and 68% admitted that half or fewer of their employees interact with agents day to day.
Teams are deploying without running the compound reliability math. They are treating demos as deployment proxies. They are piling tools onto agents without schema validation or reversibility gating. They are shipping customer-facing AI without audit trails. And they are waiting for model upgrades to solve problems that aren't model problems.
The teams that close this gap won't be the ones with the biggest infrastructure budget or earliest access to frontier models. They'll be the ones who treat their agent deployments the same way they treat any other critical system: with structured autonomy, human checkpoints at the boundaries that matter, scoped tool registries, step-level observability, and a clear answer to the question of what happens when something goes wrong.
That answer needs to exist before the first production deployment. Not after.
Shittu Olumide** is a software engineer and technical writer passionate about leveraging cutting-edge technologies to craft compelling narratives, with a keen eye for detail and a knack for simplifying complex concepts. You can also find Shittu on Twitter.
関連記事
今日のまとめ
AIデイリーブリーフで今日の重要ニュースをまとめ読み