Quickstart
Fastest path to one governed run end-to-end using the starter action customer.credit_issue—then prove a policy deny blocks execution.
Tessra turns agent actions into governed, queryable transactions inside your data warehouse. This walkthrough is not a generic API demo: you verify enforcement end-to-end in Snowflake.
What you are proving
- Deterministic policy is evaluated on submit—before any execution is queued.
- Approval is enforced when policy requires it; the run stays paused until decided.
- Execution only runs after policy allows it (and any required approval is satisfied).
- The outcome is durable data in Snowflake—use
APP.RECEIPTS_VIEWandGET_ACTION_STATUSJSON (terminal,next_step,policy_decision) as the source of truth.
Before you begin
- Tessra Native App is installed in the account you are using.
- You are connected to the consumer database where the app exposes the
APPschema. APP.DURABLE_ORGshould haveACTION_SERVICE_BASE_URLset to the Tessra-hosted Action Service roothttps://api.tessra.ai(default on install) or your own deployment; set harness secret only ifTESSRA_TEST_HARNESS_SECRETis enabled on that service.- An executor (webhook) is reachable from the Action Service for this action.
- If you will test an approval band, Slack or email approval is configured — see Configure approvals.
Step 1 — Set session context
Tessra-managed installs use ledger database TESSRA / schema CONTROL and Native App instance TESSRA_APP (see repo snowflake.yml). Adjust names only if your org renamed objects. Confirm with SELECT CURRENT_DATABASE(), CURRENT_SCHEMA(); when debugging.
USE DATABASE TESSRA;
USE SCHEMA CONTROL;
USE APPLICATION TESSRA_APP;
USE SCHEMA APP;
CALL APP.CREATE_OR_REFRESH_UI_VIEWS();Step 2 — Configure executor
Wire customer.credit_issue to a downstream webhook the Action Service POSTs to (not api.tessra.ai). For a minimal worker and callback contract, use the repo’s examples/tessra-downstream-worker/README.md. Replace the URL below with your reachable executor (local tunnel, Railway, etc.).
CALL APP.CONFIGURE_EXECUTOR(
'customer.credit_issue',
'webhook',
PARSE_JSON('{
"type": "webhook",
"url": "https://YOUR_DOWNSTREAM_HOST/tessra/webhook",
"headers": { "X-Source": "tessra-quickstart" }
}'),
TRUE
);Step 3 — Submit an allow-band request
Uses starter action customer.credit_issue. Amount 50 targets the usual <= 100 allow band when that policy is present. If your org has no rows yet, add bands in Build your own action or a starter install. Use a stable idempotency key per logical operation.
CALL APP.REQUEST_ACTION(
'customer.credit_issue',
PARSE_JSON('{"customer_id":"c_demo_1","amount":50,"currency":"USD"}'),
'prod',
'',
'ops@example.com',
'Quickstart allow-band test',
'tessra_quickstart_run_001',
'<HARNESS_SECRET>',
'https://api.tessra.ai',
'snowflake_sql',
NULL
);Capture the returned intent_id (JSON payload) for the next step.
Step 4 — Poll status
CALL APP.GET_ACTION_STATUS(
'<INTENT_ID>',
'https://api.tessra.ai',
'<HARNESS_SECRET>'
);Repeat until terminal is true in the JSON, then inspect next_step for UX branching.
Step 5 — Verify receipt
SELECT intent_id, status, policy_decision, approval_required,
execution_phase, next_step, terminal, created_at
FROM APP.RECEIPTS_VIEW
ORDER BY created_at DESC
LIMIT 10;Step 6 — Try a denied request
Submit the same action with an amount in the DENY band. With the usual starter bands for customer.credit_issue (<= 100 allow, <= 500 require approval, > 500 deny), use 1000. Expect policy_decision reflecting deny, a terminal status without webhook execution, and a row in APP.RECEIPTS_VIEW—proof the model cannot override policy.
CALL APP.REQUEST_ACTION(
'customer.credit_issue',
PARSE_JSON('{"customer_id":"c_demo_1","amount":1000,"currency":"USD"}'),
'prod',
'',
'ops@example.com',
'Quickstart policy-deny test',
'tessra_quickstart_deny_001',
'<HARNESS_SECRET>',
'https://api.tessra.ai',
'snowflake_sql',
NULL
);Poll GET_ACTION_STATUS as in Step 4, then confirm in APP.RECEIPTS_VIEW (or the Native App Receipts view) that the intent stopped at policy—no executor callback for a successful side effect.
Next
- Test an approval band — raise amount into
REQUIRE_APPROVALand resolve in Slack/email: Configure approvals, Customer refund example. - Cortex path — worksheet flow with
REQUEST_ACTION_FROM_CORTEX: Cortex first run (or the product narrative at /cortex). - Build your own action — Register keys, policy, executor and API / SQL reference.
