构建工作由 forward-deployed agent 完成，关卡掌握在你手中。五个步骤——发现、起草、验证、审批、发布——每个关键节点都由人来决策。
大多数集成工具只是把一块空白画布丢给你，然后祝你好运。Tajo 的工作方式就像一位出色的驻场工程师：研究涉及的系统，提出具体的集成方案，用真实检查证明自己的工作，然后在任何东西运行之前请求签核。不同之处在于，在 Tajo，这个签核是通过密码学强制执行的——你批准的内容，可验证地，就是实际执行的内容。
Agent 会梳理集成两端的系统。它基于一个涵盖 27 家供应商、10,345 个已记录 API 操作的 discovery corpus 工作，再加上你真实数据的仅结构样本——字段名称和类型，绝不包含值。
一份清晰易读的发现结果：涉及哪些系统、哪些对象、哪些字段，以及 agent 认为它们之间的关联是什么。此时还没有任何东西被构建或移动。
Agent 起草集成方案：来源、目标、字段映射、转换逻辑，以及同步必须满足的 consent 规则。起草基于已发现的 API 操作，而不是猜测出来的接口。
完整的草案，公开呈现——每一处映射、每一条规则，都表述得足够清楚，可以被质疑。草案不具备任何权限，无法触及生产系统。
在请求任何人批准之前，草案会先接受运行时关卡的检查：API 调用是否与真实操作类型匹配、映射是否经得起采样结构的检验，以及相关记录的 consent 规则是否真正可以被证明。consent 检查采取失败即拒绝（fail closed）——无法证明 consent 的同步不会运行，因此也无法通过验证。
每个关卡都有一份通过/未通过报告。失败信息是具体的——是哪个映射、哪条规则、哪种记录结构——所以修复变成一次对话，而不是一场考古发掘。
Agent 会把经过验证的集成提交给人来决策。它无法批准自己的工作：审批是一个人的行为，并且绑定到屏幕上所显示的确切配置的加密 digest。
确切将会运行的内容——以及一个保证：这确实就是将要运行的内容。审批是一次性的，绑定到那组确切的输入，并且在未被使用时会过期。改动一个字段，旧的审批就会失效。
获批的配置会在其 digest 下发布。执行时，运行时会证明自己正是在该 digest 下运行，强制执行 consent 规则和预算上限，并将每一次有风险的写入都置于其自身一次性、绑定输入的审批之后。
每次运行都会生成一份哈希链式、防篡改的审计日志：执行了什么、在哪次审批之下、触及了什么。这是证据，而不只是仪表盘的一面之词。
任何可能影响生产系统的步骤都会经过一道人工关卡。Tajo 的 agent 在起草和检查方面很快，但它被有意设计为无法给自己授权。
绑定 digest 的审批消除了你审查的内容与实际运行的内容之间的差距。在审批界面和生产环境之间，配置没有任何漂移的空间。
验证和 consent 检查都是失败即拒绝。一个无法证明自己安全且获得许可的集成会止步于关卡——这正是你希望从会写入你客户系统的软件中得到的行为。
上述生命周期正运行在 Tajo 的实时运行环境上：已接通 53 个集成，其中约 19 个具备写入能力，Brevo 是经认证的目标端（七个已定型目标），HubSpot 支持也正在成形。discovery corpus——27 家供应商、10,345 个 API 操作——是当你的技术栈超出已接通范围时，agent 用来起草的依据。每个阶段的真实进展详情在 集成就绪度 页面上。
加入 early access，带来一个真实的集成需求。我们会和你一起在上面运行完整的生命周期——关卡、审批、审计日志，一应俱全。