Connecting your data¶

To run WIRE on your own work items, you create two objects for each agent:

An input view that presents your work items in the shape WIRE expects.
An output table where WIRE writes the agent's results.

Both live in your own databases. WIRE provides validation procedures for each, so you can catch problems when you set up rather than when an agent runs.

Before you begin¶

The role you configure WIRE with must be able to grant the app access to your objects. That means either OWNERSHIP of the views and tables, or MANAGE GRANTS on the account. Object-level SELECT, INSERT, or UPDATE alone isn't enough. The app also needs USAGE on the parent database and schema.

Input view contract¶

Every input view must have these columns:

Column	Type	Nulls	Purpose
`ID`	`VARCHAR`	Not allowed	Unique work item identifier. Joins the input to the output table.
`UPDATED_DTM`	Any `TIMESTAMP`	Not allowed	Change detection. Only rows newer than their last result are processed.
`WORK_ITEM_INFO`	`OBJECT`	Allowed	The work item's data, passed to the agent's prompt.
`INSIGHTS`	`VARIANT`	Allowed	Additional context, such as prior results, feedback summaries, or enriched data.
`RULE_ENGINE_RESULTS`	`OBJECT`	Allowed	A pre-computed result. When set, WIRE skips the model for that row.

A NULL ID breaks the join to the output table, and a NULL UPDATED_DTM breaks change detection, so rows with either are skipped or reprocessed.

Build WORK_ITEM_INFO without listing every column

OBJECT_CONSTRUCT(* EXCLUDE (id, updated_dtm)) passes every remaining source column to the agent.

Skip the model for cases you can decide with rules

Set RULE_ENGINE_RESULTS to an object such as {'category': 'LOW PRIORITY', 'confidence': 'HIGH', 'reason': 'Rules Engine'}. WIRE writes it as the result, records engine_type = 'RULES', and makes no AI call for that row.

Example input view¶

CREATE OR REPLACE VIEW my_db.my_schema.triage_input AS
SELECT t.ticket_id::VARCHAR                                          AS id,
       t.last_modified                                               AS updated_dtm,
       OBJECT_CONSTRUCT(* EXCLUDE (ticket_id, last_modified))       AS work_item_info,
       NULL::VARIANT                                                 AS insights,
       IFF(t.status = 'Spam',
           OBJECT_CONSTRUCT('category', 'IGNORE', 'confidence', 'HIGH',
                            'reason', 'Rules Engine'),
           NULL)                                                     AS rule_engine_results
  FROM my_db.my_schema.tickets AS t;

Validate the view¶

CALL wire_native_app.main.validate_view('my_db.my_schema.triage_input');
-- Returns 'PASS' or 'FAIL: <list of violations>'

validate_view checks your data, not your DDL. It samples up to 1,000 rows and reports any NULLs it finds in ID or UPDATED_DTM. You don't need a NOT NULL declaration on the view, and Snowflake doesn't allow one.

Output table contract¶

Output tables receive agent results. Every output table needs these columns:

Column	Type	Purpose
`ID`	`VARCHAR NOT NULL`	Matches the input view's `ID`. Must have a `PRIMARY KEY` or `UNIQUE` constraint.
`WORK_ITEM_INFO`	`OBJECT`	Copied from the input view.
`INSIGHTS`	`VARIANT`	Copied from the input view.
`ENGINE_TYPE`	`VARCHAR`	`AGENT` when the model produced the result, `RULES` when the input supplied it.
`RESPONSE`	`VARIANT`	The raw model response.
`RESULTS`	`OBJECT`	The structured result, derived from `RESPONSE`.
`AGENT_METRICS`	`OBJECT`	Model name, token usage, and an `error` for rows where inference failed.
`CAT_LABELS`	`ARRAY`	The categories available to the agent.
`ETL_CREATED_DTM`	`TIMESTAMP_NTZ`	When the row was written. Must be exactly `TIMESTAMP_NTZ`.
`AGENT_EXECUTION_ID`	`NUMBER(38,0)`	Links the row to its run in `control.agent_execution`.

Triage output tables need three more columns so people can override results:

Column	Type	Purpose
`OVERRIDE_CATEGORY`	`VARCHAR`	Category assigned by a person.
`OVERRIDE_CONFIDENCE`	`VARCHAR`	Confidence of the override.
`OVERRIDE_REASON`	`VARCHAR`	Why the person overrode the agent.

Common mistakes

ETL_CREATED_DTM as TIMESTAMP_TZ or TIMESTAMP_LTZ. This causes unexpected reprocessing or type errors at runtime. Use TIMESTAMP_NTZ.
Missing RESPONSE or AGENT_EXECUTION_ID. Both are required. A table without them fails at runtime with invalid identifier.
No uniqueness constraint on ID. WIRE merges results on ID, and results are unpredictable without one.

Example output tables¶

TriageAnalysis, summary, rollup, and others

CREATE TABLE my_db.my_schema.triage_output (
    id                  VARCHAR         NOT NULL,
    work_item_info      OBJECT,
    insights            VARIANT,
    engine_type         VARCHAR,
    response            VARIANT,
    results             OBJECT,
    agent_metrics       OBJECT,
    cat_labels          ARRAY,
    etl_created_dtm     TIMESTAMP_NTZ,
    agent_execution_id  NUMBER(38, 0),
    override_category   VARCHAR,
    override_confidence VARCHAR,
    override_reason     VARCHAR,
    CONSTRAINT pk_triage_output PRIMARY KEY (id)
);

CREATE TABLE my_db.my_schema.analysis_output (
    id                  VARCHAR         NOT NULL,
    work_item_info      OBJECT,
    insights            VARIANT,
    engine_type         VARCHAR,
    response            VARIANT,
    results             OBJECT,
    agent_metrics       OBJECT,
    cat_labels          ARRAY,
    etl_created_dtm     TIMESTAMP_NTZ,
    agent_execution_id  NUMBER(38, 0),
    CONSTRAINT pk_analysis_output PRIMARY KEY (id)
);

Validate the table¶

-- Analysis, summary, rollup, and other agent types
CALL wire_native_app.main.validate_table('my_db.my_schema.analysis_output');

-- Triage: also checks the override columns
CALL wire_native_app.main.validate_table('my_db.my_schema.triage_output', 'triage');

Grant the app access¶

WIRE reads the input view and writes to the output table, so grant the application access to both:

GRANT USAGE ON DATABASE my_db TO APPLICATION wire_native_app;
GRANT USAGE ON SCHEMA my_db.my_schema TO APPLICATION wire_native_app;

GRANT SELECT ON VIEW my_db.my_schema.triage_input TO APPLICATION wire_native_app;
GRANT SELECT, INSERT, UPDATE ON TABLE my_db.my_schema.triage_output
    TO APPLICATION wire_native_app;

If you skip this step, saving the agent's configuration returns the exact GRANT statements that are missing.

Next step¶

Configure an agent that reads your input view and writes to your output table.