--- title: "How Tajo Works | Tajo" description: "Tajo's agent builds integrations through a governed lifecycle — discover, draft, validate, approve, publish — with a human decision at every gate that matters." url: https://tajo.io/how-it-works/ markdown: https://tajo.io/how-it-works.md lang: en-US alternates: {bg-BG: /bg/how-it-works.md, cs-CZ: /cz/how-it-works.md, de-DE: /de/how-it-works.md, da-DK: /dk/how-it-works.md, es-ES: /es/how-it-works.md, fr-FR: /fr/how-it-works.md, el-GR: /gr/how-it-works.md, hr-HR: /hr/how-it-works.md, hu-HU: /hu/how-it-works.md, it-IT: /it/how-it-works.md, ja-JP: /jp/how-it-works.md, ko-KR: /kr/how-it-works.md, ar-SA: /ar/how-it-works.md, nl-NL: /nl/how-it-works.md, no-NO: /no/how-it-works.md, pl-PL: /pl/how-it-works.md, pt-BR: /pt/how-it-works.md, ro-RO: /ro/how-it-works.md, ru-RU: /ru/how-it-works.md, sv-SE: /se/how-it-works.md, zh-CN: /zh-cn/how-it-works.md, sl-SI: /sl/how-it-works.md, sr-Latn-RS: /sr/how-it-works.md, th-TH: /th/how-it-works.md, tr-TR: /tr/how-it-works.md, ur-PK: /ur/how-it-works.md, vi-VN: /vi/how-it-works.md, sk-SK: /sk/how-it-works.md} --- # How Tajo builds an integration Tajo connects the systems you already run to the ones you add next, so neither side has to move. A forward-deployed agent does the building. You hold the gates. Five steps: discover, draft, validate, approve, publish, with a human decision at every point that matters. 1. Discover 2. Draft 3. Validate 4. Approve 5. Publish & run Most integration tools hand you a canvas and wish you luck. Tajo works the way a good deployed engineer does: it studies the systems involved, proposes a concrete integration, proves its work against real checks, and then asks for sign-off before anything runs. The difference is that with Tajo, the sign-off is cryptographically enforced — what you approve is, verifiably, what executes. 01 ## Discover ### What the agent does The agent maps the systems on both sides of the integration. It works from a discovery corpus of 27 vendors and 5,937 documented API operations, plus a shape-only sample of your actual data — field names and types, never values. ### What you see and approve A readable picture of what was found: which systems, which objects, which fields, and what the agent believes connects them. Nothing has been built or moved yet. 02 ## Draft ### What the agent does The agent drafts the integration: source, destination, field mappings, transforms, and the consent rules the sync must satisfy. Drafting is grounded in the discovered API operations, not guessed endpoints. ### What you see and approve The full draft, in the open — every mapping and every rule, stated plainly enough to argue with. A draft has no permissions; it cannot touch a production system. 03 ## Validate ### What the agent does The draft is checked against the runtime's gates before anyone is asked to approve it: do the API calls typecheck against the real operations, do the mappings hold against the sampled shapes, and can the consent rules actually be proven for the records involved. Consent checks fail closed — a sync that can't prove consent doesn't run, so it doesn't pass validation either. ### What you see and approve A pass/fail report per gate. Failures are specific — which mapping, which rule, which record shape — so the fix is a conversation, not archaeology. 04 ## Approve ### What the agent does The agent presents the validated integration for a decision. It cannot approve its own work: approval is a human action, and it is bound to a cryptographic digest of the exact configuration on the screen. ### What you see and approve Exactly what will run — and a guarantee that it is what will run. The approval is single-use, tied to those precise inputs, and expires if unused. Change one field and the old approval is void. 05 ## Publish & run ### What the agent does The approved configuration is published under its digest. At execution time the runtime attests it is running exactly that digest, enforces the consent rules and budget caps, and gates any risky write behind its own single-use, input-bound approval. ### What you see and approve A hash-chained, tamper-evident audit log of every run: what executed, under which approval, touching what. Evidence, not a dashboard's word for it. ## Why the gates are the point ### The agent drafts; you decide Every step that could affect a production system passes through a human gate. Tajo's agent is fast at the drafting and checking; it is deliberately incapable of granting itself permission. ### Approval means that, exactly Digest-bound approvals close the gap between what you reviewed and what runs. There is no window for the configuration to drift between the approval screen and production. ### Refusal is a feature Validation and consent checks fail closed. An integration that cannot prove it is safe and permitted stops at the gate — which is precisely what you want from software that writes to your customer systems. ## Where this runs today The lifecycle above runs against Tajo's live runtime: 55 registered integrations, 47 of which can read into a sync and 6 of which can write (Brevo, Shopify, HubSpot, Salesforce, Pipedrive and Zoho CRM). The discovery corpus, API specs from 27 vendors with 5,937 operations, is what the agent drafts from when your stack goes beyond what is already registered. The honest breakdown of what sits at each stage is on the [integration readiness](https://tajo.io/integration-readiness/) page. ## Watch it build one of yours Join early access and bring a real integration problem. We'll run the full lifecycle on it with you — gates, approvals, audit log and all. ## This page as Markdown: [how-it-works.md](https://tajo.io/how-it-works.md) Loading Markdown… [Open in Claude](https://claude.ai/new) [Open in ChatGPT](https://chatgpt.com/)