One Tool, Four Working Personas

Most AI assistants treat themselves as a single role: helpful generalist. That is fine for the first ten questions and useless after that. Real ServiceNow work splits across four distinct stances. The Business Analyst writes acceptance criteria. The architect chooses between Flow Designer and a Business Rule. The security consultant red-teams an ACL. The senior developer writes the code that ships.

Yeti AI Chat is built to wear all four of those hats deliberately. Each hat changes the framing, the depth, and the format of the response. The same instance connection underneath. The same 100,000-plus vector ServiceNow knowledge base, the same 17,000-plus code examples. Different stance.

This article walks through each hat with a concrete prompt and the kind of output it produces.

Hat 1: Business Analyst

The Business Analyst hat lives upstream of code. It is the right stance when you have a vague requirement, a stakeholder email, or a meeting transcript and you need to turn it into well-formed user stories. The output is structured: persona, narrative, acceptance criteria, edge cases, dependencies.

Prompt example: "We need to give the regional managers the ability to approve incident reassignments out of their team. Write me three user stories with acceptance criteria."

The Business Analyst hat will not jump to code. It will return something like the plain-English-to-acceptance-criteria pattern below.

Story 1: Regional manager approves outbound reassignment

As a regional manager
I want to approve any incident reassignment that moves work
  out of my team
So that I retain visibility over work my team owns

Acceptance criteria:
  - Given an incident is currently assigned to my team
    When a fulfiller attempts to reassign it to another team
    Then the reassignment is held in "Pending approval" state
    And a notification is sent to my approval queue
  - Given a reassignment is pending my approval
    When I approve it
    Then the assignment_group changes to the target team
    And work notes capture the approval audit trail
  - Given a reassignment is pending my approval
    When I reject it
    Then the assignment_group stays unchanged
    And the reason for rejection is captured in work notes

Edge cases:
  - Reassignment between two teams both under my region:
    no approval required.
  - Reassignment from a team I do not manage:
    no approval required.

Dependencies:
  - Region-to-team mapping table is current.
  - Notification preferences honour the regional manager's
    delegation rules.

The Business Analyst hat lives in the language the business uses. It is the right stance when you are scoping work, not when you are building it.

Hat 2: CMA Architect

The CMA Architect (Certified Master Architect) hat is the right stance when you have a design decision rather than a coding decision. Where does this logic live? Flow Designer or a Business Rule? A custom table or extending task? A REST API or IntegrationHub? The architect hat answers with trade-offs, not opinions.

Prompt example: "We need to synchronise a list of approved contractors between ServiceNow and our customer's SAP SuccessFactors instance. The list refreshes nightly. Should we use IntegrationHub, a scheduled job, or MID server scripts? Show me the trade-offs."

The architect hat returns a decision matrix, the recommended pattern, and the conditions under which the recommendation flips. It is also the hat that will say "do not build this" when the data suggests an OOB module already exists.

When you are working in Guru mode (described in our companion post on Yeti modes), the architect hat is even more thorough. It will pull comparable patterns from the knowledge base and cite them, so you can see where the recommendation comes from.

Hat 3: Security Consultant

The Security Consultant hat reads code the way an attacker would. It assumes the user is hostile, the auth chain is brittle, and the ACLs are wrong until proven otherwise. The output is a list of findings, with severity, with reproduction steps where possible, and with a recommended fix.

Prompt example: "Review this script include for security issues." Paste the script. The Security Consultant hat returns something like this.

Security review: ContractorImport.getContractorByEmail

Finding 1: SQL injection via unescaped query parameter
  Severity: High
  Evidence:
    var gr = new GlideRecord('u_contractor');
    gr.addEncodedQuery('email=' + email);  // 'email' is user input
    gr.query();
  Reason:
    The 'email' variable is concatenated into an encoded query
    string without sanitisation. A crafted value like
    "[email protected]^ORsys_idISNOTEMPTY" returns every record.
  Fix:
    Use addQuery with explicit operator:
      gr.addQuery('email', email);
    Or sanitise before concatenation:
      var safe = String(email).replace(/[^a-zA-Z0-9@._-]/g, '');

Finding 2: Missing role check on caller
  Severity: Medium
  Evidence:
    No gs.hasRole() check; any authenticated user can call.
  Fix:
    Wrap entry point with:
      if (!gs.hasRole('contractor_admin')) {
          return null;
      }

Finding 3: gs.log emits PII into system log
  Severity: Low
  Evidence:
    gs.log('Lookup for ' + email);
  Fix:
    Replace with structured log to a dedicated table with
    appropriate ACLs, or hash the email before logging.

The Security Consultant hat is the right stance for ACL design, code review before promotion, and any time you are about to expose an endpoint. It will not soften its findings to keep you comfortable.

Hat 4: Senior Developer

The Senior Developer hat is the closest to what most people imagine an AI coding assistant does. The difference is in the standard. The Senior Developer hat writes code that would survive a critical pull-request review: named variables, defensive null checks, consistent logging, sensible commit boundaries. It also writes tests where they belong.

Prompt example: "Write a before insert Business Rule on change_request that prevents creation when the requested start date is in the past, with an inline unit test."

// Before Insert Business Rule on change_request
// Order: 100
// Condition: current.start_date.changesTo() (or similar)
(function executeRule(current, previous) {
    var startDate = current.getValue('start_date');
    if (!startDate) {
        return; // Let other rules handle the missing-value case.
    }

    var requested = new GlideDateTime(startDate);
    var now = new GlideDateTime();

    if (requested.before(now)) {
        current.setAbortAction(true);
        gs.addErrorMessage(
            'Requested start date must not be in the past.'
        );
    }
})(current, previous);

// Companion ATF test:
//   Suite: Change Request validation
//   Step 1: Impersonate itil user
//   Step 2: Open new change_request
//   Step 3: Set start_date to (now - 1 day)
//   Step 4: Submit
//   Assert: Form blocks submit with error message containing
//           "must not be in the past".

The Senior Developer hat is the right stance for the actual coding work. It is also the hat that will refuse to write code when the requirement is ambiguous, and will route the conversation back to the Business Analyst hat to clarify acceptance criteria.

Choosing the Right Hat

The hats are not formal modes you toggle. They are framings Yeti AI Chat picks up from the way you prompt. A useful habit is to say the hat out loud at the start of the prompt: "As a security consultant, review this." or "As a senior developer, implement the following." That instruction shapes the response and saves a follow-up round.

In practice, most non-trivial pieces of work cycle through all four. Start in BA. Decide in architect. Write in developer. Review in security. Then promote. Yeti AI Chat is built around that loop because the loop is the loop senior ServiceNow practitioners already run.

Yeti AI Chat is available on every tier of SnowCoder, including the Standard tier. The four hats described here come with the product, not with an upsell.

The Four Hats of Yeti AI Chat: BA, Architect, Security Consultant, Senior Developer