業務アプリに agent をつなぐと、「一度 model を呼べるか」はすぐにもっと難しい設計問題へ変わる。API configuration は誰が持つのか。tool call は確認を求めるべきか。session は再起動後もどう続くのか。失敗した workflow をどう再現するのか。CLI と embedded SDK が別々の挙動に分かれないか。Python に chat loop を一つ置くだけでは、こうした境界は解決しない。一方で最初から hosted platform に寄せると、runtime state と data governance もまとめて預けることになりやすい。

今日見る jin-bo/agentao は、Python host に埋め込める local-first の「governed agent runtime」と名乗る project だ。自分の app に Agentao(...) として組み込めるほか、terminal CLI や ACP server としても動く。tool confirmation と四つの mode、MCP/ACP、SQLite-backed persistent memory、skills、sub-agents、multi-session control、JSONL session replay を、application ごとに組み立てるのではなく同じ runtime に入れている。

GitHub repository page、README、LICENSE、main branch、Releases page を 2026-09-18 10:05 Asia/Shanghai 時点で確認すると、jin-bo/agentao は 303 stars、11 forks。主要 language は Python、license は MIT。repository は 2026-02-10 01:30:42 UTC に作成された。main の latest push/HEAD は a2c8c6d、時刻は 2026-09-18 09:42:00 UTC で、0.5.0 で削除する API の準備が中心だ。最新 GitHub Release は v0.4.27、published at は 2026-09-18 09:18:41 UTC。つまり main は最新 stable release より先に進んでいるため、production integration では main を追うより release を pin したい。

プロジェクト概要

項目内容
リポジトリjin-bo/agentao
位置づけ埋め込み可能、local-first の Python governed agent runtime
Stars / Forks303 / 11
主要 languagePython
ライセンスMIT
作成日2026-02-10 01:30:42 UTC
Latest push / main HEAD2026-09-18 09:42:00 UTC / a2c8c6d
最新 Releasev0.4.27、2026-09-18 09:18:41 UTC
protocol と記録MCP（stdio / Streamable HTTP / SSE）、ACP、JSONL replay

面白いのは host contract を明確にしている点

README の最小埋め込み手順は pip install agentao のあと、Agentao、LLMClient、transport を明示して作る形だ。この path は environment discovery、implicit network、global state を持たないと明記されている。working directory、model client、transport は host が渡す。すでに Web service、queue consumer、desktop app を持つ team にとって、この境界は「env を自動で読み、自分で起動する」方式より扱いやすい。credential の出所、network egress、lifecycle を application 側に残せるからだ。

もう一方の agentao[cli] は terminal 利用者に同じ runtime を提供する。CLI の /mode は read-only、workspace-write、full-access、plan を切り替えられる。/plan は read-only の計画を .agentao/plan.md に置き、/memory は persistent memory、/mcp list は server state を確認する。embedded と CLI を別製品にせず、permissions、protocols、session semantics を共有させているのがポイントだ。

governance を tool call の前に置く

Agentao の “governed” は単なる label ではない。README では constraint layer に tool confirmation、四つの permission mode、macOS の sandbox-exec を置く。connectivity layer は MCP の stdio、Streamable HTTP、SSE と、full-agent JSON-RPC である ACP を扱う。observability layer には streaming tool output、LLM logging、.agentao/replays/ の JSONL replay がある。「agent はなぜこの file を変更したのか」を振り返る workflow なら、replay は少なくとも event record の確かな置き場になる。

memory も black-box の cloud service としては説明されていない。README は SQLite-backed、user/project の二 scope を持つ persistent memory と automatic recall を挙げる。skills は skills/ から自動発見でき、owner/repo[:path][@ref] 指定で GitHub から install もできる。sub-agent には built-in role と .agentao/agents/ による custom entry point がある。file layout と storage location を自分で管理したい Python app には合うが、retention、backup、team sharing の方針は自分で決める必要がある。

最小権限で実際の task から始める

project は Python 3.10+ を要求する。README の CLI example は API key、base URL、model の三項を必要とし、Anthropic、Gemini、DeepSeek、その他の OpenAI-compatible provider へ対応する environment-variable の道も示している。堅実な導入順序は、production ではない working directory でまず read-only または plan mode にし、明確な task を一つ走らせることだ。tool confirmation、log、replay に何が残るかを確認してから、isolated workspace で workspace-write を有効にし、最後に full-access や remote MCP を検討したい。

permission mode、confirmation prompt、replay が完全な data isolation を自動で作るわけではない点には注意したい。agent の prompt、tool output、path、session metadata が log や memory に入るかは、自分たちの data classification に照らして確認が必要だ。macOS sandbox も cross-platform な security boundary と同義ではない。特に latest main は 0.5.0 向けに旧 API の削除を進めているため、embedded caller は dependency version を固定し、自分の integration tests を走らせ、upgrade 前に migration document を読むべきだ。

まとめ

jin-bo/agentao を試す理由は、MCP、memory、sub-agent をまた一通り並べたことではない。Python host が握れる contract の中にそれらを置こうとしている点にある。application が client と transport を渡し、runtime が permission mode、protocol integration、session record、replay を受け持つ。agent capability は欲しいが execution control と observability を丸ごと外部に任せたくない Python tool なら、まず embedded の最小構成と read-only mode で一つの実 workflow を試し、その後に tool permission と persistence の範囲を広げる判断がよさそうだ。

プロジェクト: https://github.com/jin-bo/agentao