Deployment
The engines inside your pipeline.
Krine, Tholo, and Basano do not replace a delivery pipeline. They sit inside one. This page is the reference shape for standing them up in a team's existing CI/CD and data stack, written for the engineer who does the deploying: what sits where, what it reads, and where each engine stops.
The one rule the whole shape enforces
Engines propose and stop. Every change an engine produces arrives as a held draft pull request. CI verifies it. A person merges it. Nothing on this page relaxes that rule. The pipeline exists to make it structural rather than behavioral: branch protection, required status checks, and review requirements mean an engine could not merge even if it tried.
Where each engine sits in the pipeline
Krine sits before the branch.
It reads demand and outcome data from the metric warehouse, ranks the backlog with auditable rubric constants, and emits a stop package. The stop package is the input to a dispatch. Krine never opens the branch itself.
Tholo sits at the pull request.
It plans the task, selects the few catalog skills the task needs, and prepares the build. Tholo stops at the execute seam by design; the executing agent opens a draft pull request and holds it there.
Basano sits in the checks, twice.
Pre-merge, prove skills run as required status checks against the branch build, so a failing verdict blocks the merge the same way a failing test does. Post-deploy, a live audit runs against production and confirms that what shipped matches what was proved. The gap between those two runs is where deploy-time regressions hide, which is why both exist.
The data plane: two stores, one access contract
BigQuery is the metric warehouse. Search Console's bulk export and GA4's native export both land daily tables in BigQuery directly. There is no ingestion pipeline to build; Google runs it. The one time-sensitive action: turn the exports on before anything else, because they do not backfill. The history starts the day the export is enabled, and that clock only runs forward.
A Postgres store is the operational system of record. Run records, decisions, and the agreement log live here (we run Supabase). Metric history does not. Keeping the two stores separate is deliberate: the warehouse answers "what happened to the numbers," the operational store answers "what did the engines and the humans decide."
The engines reach data through MCP servers, read-only. Google ships a managed remote MCP server for BigQuery, with OAuth and IAM handling authorization and tools covering schema inspection and query execution, and an official MCP for GA4. Those cover the raw access. What remains to build is thin: a domain layer that encodes your queries' correctness rules. Two examples of what that layer knows that a raw SQL tool does not: Search Console's export stores position zero-based, so average position must be computed with the offset, and every call must carry a date range pushed down as a partition filter, so a query scans the requested days and never the full history. A call without a date range gets rejected, not silently run. That is the cost guard and the correctness guard in one place.
The shape is warehouse-agnostic. The same pattern runs on Snowflake through its managed MCP server, and dbt's MCP adds model lineage and Semantic Layer queries between the warehouse and the engines. The engines consume the access contract, not the vendor.
The access rules
These are the guardrails a deployment carries on day one, not hardening added later.
Read-only by default. The sensing and analysis paths carry no write tools. Submitting a sitemap, requesting indexing, or changing an analytics setting is a state-changing action a human authorizes, and it does not live in these servers.
Least privilege at the platform layer. The MCP's service identity gets dataset-scoped read access and IAM deny policies for everything else, so the access contract is enforced where the data lives, not only in the tool code.
Mandatory bounds on every query. The date filter rule above applies to every warehouse call. Unbounded scans are a cost incident waiting for a cron job.
Credential hygiene. Keys live in the environment, never in tool output or error messages, and never come from page content or observed data.
Engines never merge. Stated once more because it is the rule the rest depend on.
Week one, forward-deployed
The order matters, and the first step is the one with a clock on it.
Enable the exports. Search Console bulk export and the GA4 BigQuery link, on every property in scope. Do this before any build work; no backfill means every day of delay is a day of missing history.
Stand up the two stores. Pick the BigQuery region once and match it across both exports, since it cannot be changed later without a migration. Provision the operational Postgres store.
Wire the managed MCPs, read-only. BigQuery's managed server and the GA4 server, authenticated with a scoped service identity.
Run Krine against real demand data and whatever outcome history exists. The first stop package is usually a ranking of work the team already suspected, which is the point: the rubric makes the suspicion auditable.
Run the first Tholo dispatch and let it land as a held draft pull request. Review it the way you would review a contractor's first PR.
Put Basano in the checks. Prove skills as required status checks on the next PR, and a live audit after the first merge deploys.
Start the agreement log on day one. Every run records the engine's verdict and the human's verdict side by side. That record is what eventually licenses more autonomy, and it only counts if it starts at the beginning.
Open where it should be, operated where it counts
The tool shapes, the artifact schemas, and the skills catalog are public. The running instance is not what you download: authenticated against your properties, tuned with your rubric constants, carrying your agreement history. The contract is open. The operation is the product.
Continue reading
The engines hub: what each engine does on its own. The engines
BigQuery integration: Google's managed MCP in detail. BigQuery
Snowflake and dbt: the same shape on a different warehouse. Snowflake dbt
The skills catalog the engines select from. Skills catalog
FAQ
What does a forward-deployed engine setup look like?
One engineer, one week, in this order: enable the warehouse exports, stand up the metric warehouse and the operational store, wire read-only MCP access, then run the three engines through one real cycle ending in a human merge. The engines arrive as tools inside the team's existing pipeline, not as a platform beside it.
Do the engines ever write to production?
No. Engine output arrives as held draft pull requests. Branch protection and required status checks make the human merge structural. The data-access layer is read-only; state-changing actions against external services stay with a person.
Which data warehouses does this work with?
The reference shape uses BigQuery because Search Console and GA4 export there natively with no pipeline to build. The same pattern runs on Snowflake through its managed MCP server, with dbt's MCP as an optional lineage and semantics layer. The engines consume the access contract, not the vendor.
What has to exist before the engines are useful?
A repo with CI, a warehouse with at least some outcome data accumulating, and a person who merges. The exports are the long pole because they do not backfill, which is why enabling them is step one.