Scoped App Builds with the Yeti Build Agent: From Brief to Audited Deploy

The Real Cost of a Scoped App

A scoped application in ServiceNow is more than a logo and a few tables. To land cleanly in production it needs a properly scoped sys_app record, tables with sensible columns and ACLs, business rules, client scripts, UI policies, REST endpoints, role definitions, a navigation module, fixtures, and tests. Then it needs to be packaged in update sets or a build artifact, run through a security review, and deployed without breaking anything else in the instance.

For most teams the bottleneck is not creativity. It is the dozens of small artifacts you need to wire together correctly. Miss a single ACL and the whole app is a security incident waiting to happen.

The SnowCoder Yeti Build Agent exists to remove that bottleneck. It takes a written brief, runs it through a 10-stage pipeline, and produces a scoped app that has been validated, tested, and audited before it ever touches your target instance.

The 10-Stage Build Pipeline

The Yeti Build Agent is not a single prompt. It is a deterministic pipeline made of ten stages, each with its own validation rules and gating criteria. Stages do not advance until their outputs pass.

On our internal benchmark of 291 stories spanning vendor risk, asset, HR, and ITSM patterns, the pipeline produces a deployable scoped app for every story it accepts. Stages 7, 9, and 10 each have explicit pass/fail gates that block deployment if expectations are not met.

From Brief to Fluent SDK Source

The Yeti Build Agent emits its output as @servicenow/sdk source, the ServiceNow Fluent SDK. Fluent now covers 42 artifact classes, which is the full surface of what most scoped apps need. Because the output is real source code, it lives in git, reviews like code, and deploys like code.

A typical brief looks like this:

After the Data Model and Fluent CodeGen stages, the table definition lands as Fluent source:

import { Table } from '@servicenow/sdk/core';

export const x_acme_vrr_vendor = Table({
    name: 'x_acme_vrr_vendor',
    label: 'Vendor',
    extends: 'sys_metadata',
    columns: {
        name: { label: 'Name', type: 'string', mandatory: true, max_length: 100 },
        risk_rating: { label: 'Risk Rating', type: 'integer', min: 1, max: 5, default: 3 },
        contract_expiry: { label: 'Contract Expiry', type: 'glide_date' },
        owner: { label: 'Owner', type: 'reference', reference: 'sys_user' },
        review_due: { label: 'Review Due', type: 'glide_date', read_only: true },
    },
    accessControls: ['vendor_admin', 'vendor_read'],
});

The business rule from the same brief is emitted next, alongside its before-insert pattern and an explicit access control reference. Nothing is implied. Every artifact is enumerated.

import { BusinessRule } from '@servicenow/sdk/core';
import { x_acme_vrr_vendor } from './tables/vendor';

export const setReviewDue = BusinessRule({
    name: 'Set Review Due',
    table: x_acme_vrr_vendor,
    when: 'before',
    action: 'insert',
    script: `(function executeRule(current, previous) {
        var gdt = new GlideDateTime();
        gdt.addDaysUTC(365);
        current.review_due = gdt.getDate();
    })(current, previous);`,
});

ATF Tests Generated Alongside the App

Stage 7 is non-negotiable. The Yeti Build Agent will not move on to packaging until ATF tests exist for the acceptance criteria captured in stage 2. Tests are generated in the same Fluent project, run against a sandbox instance, and their results are recorded against the build.

For the Vendor Risk Register brief, the agent generates assertions like "inserting a vendor with no review_due populates review_due to today + 365 days" and "the REST endpoint returns 401 without the vendor_read role." Each assertion maps back to a user story.

If a test fails, HealBudget kicks in. The agent will attempt up to 5 self-healing iterations on the failing artifact, drawing on the 100,000+ vector ServiceNow knowledge base and 17,000+ code examples that make the SnowCoder model 60% more accurate than generic LLMs on the 120+ ServiceNow benchmarks we track on the benchmarks page. If those attempts exhaust without a pass, the build is marked failed and surfaced to the operator. The pipeline never silently downgrades.

Security, Update Sets, and the Audited Deploy

Stages 8 and 9 are the gate between a working app and a deployable app. The update set verification step walks every artifact in the Fluent output and confirms it appears in the captured update set. If a script include is generated and referenced but not captured, the build fails verification.

The Security & Script Audit step then runs the artifact set through the same checks used by Instance Audit, including ACL coverage by table and operation, evaluations of gs.executeNow patterns, role escalation risk, and unsafe Glide APIs. The audit is recorded as a structured report attached to the build. You can read more about the deeper instance-wide version on the Instance Audit page, which covers 500+ granular checkpoints.

Stage 10 deployment is governed by HealBudget and by destructive-change confirmation gates. Any removal of a previously deployed artifact requires explicit confirmation. Spend is capped per-build by HealBudget so a runaway loop cannot drain tokens. The target instance can be a sandbox, a sub-prod stack, or production, and every push records its destination, actor, and the diff applied. Full pipeline detail lives on the Yeti Build Agent product page.

Where the Yeti Build Agent Fits

The Yeti Build Agent is part of the Enterprise tier. Yeti AI Chat, which is the entry point for everyday Business Rule, Client Script, and ACL generation, is on every tier including Standard. Pricing detail is on the pricing page.

The right mental model is this. Use Yeti AI Chat to author the bricks. Use the Yeti Build Agent when you need to assemble those bricks into a whole, audited scoped app. The supported release floor is Zurich. If your target instance is on Zurich or later, the Fluent output will load cleanly.

Related Reading