本文へスキップ
ステートレスな MCP Streamable HTTP から、どのエージェントでも Action Engine を呼び出せるようになりましたお知らせを読む

ユーザーはすでにエージェントを選んだ。製品をそれに対応させる。

製品は、仕事の正しい進め方をすでに知っています。Invokta はその知識を、どのエージェントからでも呼び出せるアクションにまとめます。

3 つの異なる呼び出し側が、ひとつの Action Engine を呼び出します。エンジンはケーパビリティを所有し、検証済みの同じ結果をすべての呼び出し側に返します。 clinic-engine 上の appointments.schedule を Claude, ChatGPT, Hermes が呼び出しています。

患者がどのアシスタントを使っても、予約ルールはアクションの中で一度だけ動きます。

01 / 06課題
作るか、呼ばせるか

自前のハーネスを作るか、製品を呼び出せるようにするか

どの製品も、いままさに自前のエージェントを作ろうとしています。しかしそのスタックのほとんどは、あなたの本業ではありません。もう一つの道: 顧客がすでに使っているハーネスが、あなたの製品にしかできない部分を呼び出します。

あなたの製品
本業ではない 7 個の部品チャットUIエージェントループモデルとルーティングメモリとコンテキストプロンプトとガードレール権限と制限評価と品質ユーザーが採用すべきエージェントがまた増えしかもあなたのアプリしか知らないClaudeChatGPTHermesすでに存在し、すでに選ばれている呼び出すAction Engineorders.request-refund注文の適格性必要な証跡決定の記録検証済みの決定が、顧客自身のエージェントに届く返金ポリシー

あなたのものは、ここだけ

本業ではないインフラに数か月を費やし、最後は Claude や ChatGPT とユーザーの時間を取り合うことになります。

不良品だったスニーカーの返金を頼んで。

完了: 交換ポリシーに沿って承認。3 日以内に 249 ドル返金されます。

02 / 06アクションレイヤー
成果が起点

素のツールから、信頼できる成果へ

MCP ツールが公開するのはひとつの操作です。Invokta の Action Engine は仕事そのものを届けます。どの順番で実行するか、誰が呼べるか、正しい結果には何が含まれているべきか。

  • プリミティブではなく成果

    組み合わせ方をエージェントに推測させる素のツール 6 つではなく、engineering.prepare-implementation を公開します。

    詳しく見る
  • ひとつの実行経路

    すべてのアダプターが engine.invoke を呼ぶため、バリデーション、認可、エラー処理が入口ごとに分岐することはありません。

    詳しく見る
  • どのエージェントからでも新着

    ひとつのアクションに、MCP、CLI、HTTP、直接呼び出しのどこからでも届きます。呼び出し側が変わっても、振る舞いは変わりません。

    詳しく見る
03 / 06最小で役に立つエンジン
開発者が起点

ひとつのケーパビリティを、あらゆる入口から

ケーパビリティ ID はエンジンのマップに属します。ケーパビリティ自体には、すべての入口が再利用する契約と実装が入っています。

import { createEngine, defineCapability } from "@invokta/core";import { z } from "zod"; const createWelcomeMessage = defineCapability({  title: "Create a welcome message",  description: "Creates a short welcome message for a new team member.",  input: z.object({ name: z.string().trim().min(1) }),  output: z.object({ message: z.string().min(1) }),  access: "authenticated",  async run({ input }) {    return { message: `Welcome, ${input.name}!` };  },}); export const engine = createEngine({  name: "hello-engine",  version: "0.1.0",  capabilities: {    "onboarding.create-welcome-message": createWelcomeMessage,  },});
{  "message": "Welcome, Ada!"}

出力は契約に照らして検証済み

04 / 06再利用できるエンジン
ユースケース

ドメインのアクションを、すべての業務領域へ

ここに並ぶチームはどこも、新しいエージェントが来るたびに同じプロセスを教え直しています。アクションとして公開すると、こうなります。

  • コンテンツ・クリエイティブ

    エージェントごとに制作プロセスを作り直すのではなく、ブランドに沿ったプロバイダー連携のケーパビリティで、動画を編集しソーシャルカルーセルを制作します。

    見る
  • エンジニアリング

    リポジトリの文脈、アーキテクチャ、設計、リスク、受け入れ基準、テスト戦略を使って、チケットを実装可能な作業に変換します。

    見る
  • マーケティング

    ポジショニング、オーディエンス調査、根拠、チャネルの制約に基づいて、製品ローンチをブランドに沿ったキャンペーンに変換します。

    見る
  • 営業

    承認済みのテンプレート、ビジュアルアイデンティティ、価格、訴求を保ったまま、CRM の文脈からアカウント別の提案を生成します。

    見る
  • 医療オペレーション

    有効な予約枠を一覧し、クリニックの規定と認可された Google Calendar 連携を通して患者の予約を登録します。

    見る
  • 人事・採用

    レビュー可能な評価基準を適用し、選考の根拠を採用システムに記録し、人による確認が必要なときは採用チームに通知します。

    見る
05 / 06呼び出しパイプライン
境界のための設計

いつ呼ぶかはエージェント、どう動くかはエンジン

バリデーション、認可、キャンセル、エラー変換は、どの呼び出し元も結果を受け取る前に、エンジンの中で一度だけ行われます。

  • 実行時に守られる契約

    入力と出力は呼び出しのたびに検証されます。 ケーパビリティは実装と並べてスキーマを宣言します。そのため不正なリクエストはエンジンの実行前に拒否され、契約に合わない結果が呼び出し側に届くことはありません。

    契約を見る
  • ひとつのパイプライン、4 つのアダプター

    すべてのアダプターが engine.invoke を呼び出します。 アプリケーションコード、CLI、MCP stdio、ステートレスな MCP Streamable HTTP はすべて同じ実行経路に解決されるため、提供面ごとに振る舞いが分かれることはありません。

    契約を見る
  • 認可はドメインの中に

    アクセスルールはあなたのエンジンが評価します。 各ケーパビリティは明示的なアクセスルールを持ち、ドメインポリシーは呼び出し境界の内側で実行されます。呼び出すエージェントごとに実装し直す必要はありません。

    契約を見る
  • 予測できる失敗

    キャンセルとエラーはひとつの体系に従います。 中断された呼び出しと失敗は、文書化されたエラー型の集合に対応づけられます。呼び出し側はアダプター固有のメッセージを解析せず、安定した形で分岐できます。

    契約を見る
06 / 06境界
アーキテクチャ

エージェントは顧客のもの。ケーパビリティは、あなたの製品のもの

エージェントもモデルも変わっていきます。製品が公開するドメインのアクションを、そのたびに作り直す必要はありません。MCP、CLI、HTTP は、届けるための経路にすぎません。

  • Claude
  • ChatGPT
  • Hermes
  • CLI
  • アプリ
呼び出し側
engine.invoke
Invokta
  • プロバイダー
  • スクリプト
  • テンプレート
  • データ
  • ルール
プロバイダー
はじめる

もうひとつのエージェントを作らない。製品を呼び出せるようにする。

入力、出力、アクセスルールとともに、ケーパビリティをひとつ定義します。タスクは一度だけ作り、コード、CLI、MCP から呼び出します。