Build ServiceNow in a continuous loop.
A reference for everything GeneWorks — the agents, the SDLC pipeline, impact analysis, the wizards, governance, and how the platform learns your instance over time.
What is GeneWorks?
GeneWorks is the continuous delivery loop for ServiceNow. A coordinated team of 32 specialist AI agents takes a requirement, runs it through a six-stage SDLC, and stops at two human sign-offs — design sign-off before the build, verification sign-off before it ships. Same SDLC your CAB and your auditor expect. Half the hours.
At its core, GeneWorks is a multi-agent system orchestrated by Gene. Gene routes work across the agent roster — functional consultants, solution architects, ITSM/ITOM/CSM/HRSD specialists, scoped app engineers, ATF and Selenium testers, Genewriter, and the operations agents that keep the workspace coherent. Each specialist runs the same internal skill chain — Architect → Functional → Coder → ATF Tester → Selenium Tester — to produce complete, tested artifacts.
The result is a complete, auditable artifact — design rationale, working code, ATF run history, functional-test evidence, and a CAB-ready change package. GeneWorks never deploys to production. Two human sign-offs are non-negotiable: nothing builds without design sign-off, nothing ships without verification sign-off.
- 32 Agents · 5 Groups: Strategy & Design (5), Build (11), Quality (5), Documentation & Compliance (5), Operations + Gene (6+1). The agents see each other's work in the same workspace.
- Two Human Sign-offs: Design sign-off before any code is written. Verification sign-off before anything ships to CAB. Production deploys are always human-driven.
- Full ATF Coverage: ATF generated alongside the code, not bolted on after. Selenium runs cover UI flows. Screenshots, logs, and run history attach to every story.
Core Concepts Glossary
A reference for the key terms you'll encounter throughout GeneWorks documentation and the platform itself.
- Agent — A specialist AI unit scoped to a discipline within ServiceNow delivery. GeneWorks operates a roster of 32 agents in five groups. Each has its own tooling and prompts tuned for reliable output on its artifact type. Agents are orchestrated by Gene and never operate independently in production contexts.
- SDLC Pipeline — GeneWorks' six-stage continuous loop: Requirement → Design (sign-off) → Task Planner → Execute → SN Deploy → Verify (sign-off). Both sign-offs are non-negotiable.
- Impact Analysis — An automated pre-build risk assessment across eight ServiceNow health dimensions (H1–H8). Scores each and produces a composite risk level — Low, Medium, or High — before a single line of code is written.
- Update Set — A ServiceNow mechanism for capturing configuration changes as a portable package. Every GeneWorks build is a named Update Set, scoped to never land in Default. You preview and commit — GeneWorks never touches production.
- Training Corpus — The agents are trained across the entire ServiceNow knowledge surface — product docs, release notes, fixes, YouTube transcripts, community notes, partner methodologies, support docs, and GeneWorks' own delivery IP — backed by an embeddings store.
- Self-Healing — When a build or test fails on a known pattern, the agents repair and re-run it automatically (one-click Fix ATF / Fix FT in Verify). Failures that can't self-heal are flagged for human review.
- Lessons Learned — The agents write every mistake to a lessons-learned file they read before acting — so the platform stops repeating errors and gets sharper on your instance.
- ATF — Automated Test Framework, ServiceNow's native testing engine. GeneWorks writes ATF suites (server + client) for every build and runs them on its own test runner — no ServiceNow ATF cloud-runner license — alongside live-browser functional tests.
- HITL — Human-in-the-Loop. The governance framework that determines when a human must review and approve. Required after Stories, triggered during Build for Medium risk, and a full stop for High risk.
- MASTER_STATE — Gene's internal state tracker for each task. Records current stage, impact score, agent assignments, artifact references, and all review decisions — a single source of truth for task progress.
How GeneWorks is Different
Traditional ServiceNow implementation relies on certified consultants, fixed-price statements of work, and months of lead time. GeneWorks eliminates that dependency without eliminating governance.
| Dimension | Traditional SI Approach | GeneWorks |
|---|---|---|
| Time to first artifact | Days to weeks (scoping, SOW, sprint planning) | Minutes (prompt to Build stage) |
| Skill requirement | Certified developer + functional analyst | Anyone who can describe a business requirement |
| Impact awareness | Developer judgment, peer review | Automated H1–H8 analysis before any code runs |
| Testing | Manual QA, often skipped under time pressure | ATF + functional tests, mandatory before delivery |
| Institutional knowledge | Lives in developers' heads, lost on turnover | Captured in the persistent workspace + lessons-learned, permanently |
| Rollback | Manual reversal, risky, often impossible | Update Set backout — clean, instant, audited |
| Audit trail | Change records, often incomplete | Every action logged: entity, timestamp, agent, risk, before/after |
| Cost model | Per-hour consulting, $150–$350/hr | Platform subscription, unlimited builds |
Architecture Overview
GeneWorks operates as a local-first intelligence layer that connects to your ServiceNow instance via standard REST APIs. No agents live inside ServiceNow. No data leaves your machine.
You (plain-English requirement) → Gene Chat → Gene (orchestrator + knowledge) → specialist agents (ITSM, ITOM, Platform Admin, Integration) → REST API → ServiceNow (Dev / PDI / UAT instance).
- SDLC Pipeline — 6-stage structured execution from design to delivery.
- Impact Analysis — H1–H8 risk scoring before any code runs.
- Knowledge — Trained corpus + self-healing + lessons learned.
- Local-First — No data leaves your machine. Credentials never transmitted.
Prerequisites
Before your first GeneWorks build, here's everything you need ready. Setup takes roughly 20 minutes for most teams.
- Required · ServiceNow Non-Production Instance — A Personal Developer Instance (PDI), development, or UAT environment. GeneWorks never connects to production.
- Required · Admin Credentials — An account with the
adminrole. GeneWorks needs elevated permissions to create and manage Update Sets. - Time · ~20 Minutes for Setup — Initial connection and first build typically takes under 20 minutes. Subsequent tasks start immediately.
- Optional but Helpful · Existing Documentation — Any TDDs, KB articles, process specs, or scripts you want Gene to consider. Upload them to the Knowledge Base for RAG-enhanced responses.
Instance Requirements
GeneWorks supports all current and recent ServiceNow releases. No additional plugins are required for the core platform.
| Release | Status | Notes |
|---|---|---|
| Yokohama | Fully Supported | Current release. Recommended. |
| Xanadu | Fully Supported | All features available. |
| Washington DC | Fully Supported | All features available. |
| Vancouver | Partial Support | Core ITSM and Platform Admin. ITOM limited. |
| Utah & older | Not Supported | Please upgrade to Washington or later. |
Plugin Requirements: None. GeneWorks operates entirely through ServiceNow's standard REST APIs — no custom plugins, no MID Server config, no application installs for the core platform. The ITOM Discovery and Service Mapping phases of the ITOM Wizard require the Discovery and Service Mapping plugins already activated; the wizard verifies plugin status in Phase 1 and alerts you to gaps before proceeding.
Connecting Your Instance
Connection takes under two minutes.
- 1 · Open Settings Panel — Click the Settings (gear) icon in the left navigation, then the Instance Connection tab.
- 2 · Enter Your Instance URL — Format:
https://your-instance.service-now.com. No trailing slashes or path segments. - 3 · Enter Admin Credentials — Username and password for an account with the
adminrole. Credentials are stored locally on your machine and never transmitted to GeneWorks servers. - 4 · Run Connection Test — Click Test Connection. GeneWorks verifies reachability, authenticates, and confirms the release version. A green check indicates success.
- 5 · Save and Proceed — Click Save Connection. Return to Settings anytime to update credentials, switch instances, or disconnect.
Your First Build Request
- 1 · Open Gene Chat — The conversational interface for architectural discussions, quick questions, and Brainstorm sessions.
- 2 · Write a Clear Prompt — Be specific about module and outcome. E.g. "Create a Priority 1 SLA definition for the Incident table that triggers a breach notification to the assignment group manager after 30 minutes."
- 3 · Gene Returns a Summary — An impact-level assessment and blueprint summary — what it plans to build, what it assessed, what it needs confirmed.
- 4 · Start a Task in Let's Build — Gene runs the full SDLC pipeline, pausing for your approval at the Stories stage before any code is written.
- 5 · Review and Receive Your Update Set — After build and UAT pass, the task moves to Completed: Update Set name, delivery summary, and ATF results. Preview in ServiceNow and commit on your schedule.
Instance Policy
GeneWorks operates exclusively in lower ServiceNow environments. This is a deliberate product decision, not a technical limitation. GeneWorks never connects to production — the connection test actively detects production instances and refuses to proceed. There is no override.
Why lower environments only? GeneWorks is a build system, and build systems belong in lower environments. Production changes should always be initiated by a human-reviewed, tested artifact — exactly what GeneWorks produces: a named Update Set, validated by ATF, ready for CAB review and production commit on your terms. This separation protects production from the exploratory, iterative nature of agentic development.
Gene — The Orchestrator
Gene is the central intelligence of GeneWorks — the only entity your users interact with directly. Behind the scenes it manages the entire agent network, pipeline state, and memory system.
Role: Manager of Managers. Gene does not build ServiceNow artifacts itself. It understands requirements, routes to the right specialist, enforces governance, synthesizes outputs, and maintains the authoritative MASTER_STATE for every active task.
What Gene does: Requirement intake (parses natural language into structured work), domain routing (selects the correct specialist), impact-analysis enforcement (ensures H1–H8 before build), output synthesis (aggregates agent outputs), MASTER_STATE updates (canonical task state throughout the pipeline).
What Gene delegates: Technical design → Architect skill · Code generation → Coder skill · ATF test writing → ATF Tester skill · UI validation → Selenium Tester skill · REST execution → integration layer.
Gene's Routing Logic
Gene evaluates each requirement against a routing taxonomy — primary domain keywords, the ServiceNow tables/objects referenced, and workspace context from previous sessions.
| Requirement Keywords | Routed To | Domain |
|---|---|---|
| Incident, Problem, Change, SLA, Catalog, Knowledge, Request | ITSM Agent | IT Service Management |
| Discovery, CMDB, CI, MID Server, Service Mapping, Event, Alert | ITOM Agent | IT Operations Management |
| ACL, Role, License, User, Plugin, Audit, Performance, Admin | Platform Admin Agent | Platform Administration |
| REST, API, webhook, IntegrationHub, Jira, Slack, SCCM, third-party | Integration Agent | Integrations |
The Agent Network
GeneWorks operates a roster of 32 specialist agents in five groups. Every group runs in coordination on every workspace — agents see each other's work, share context, and Gene routes between them.
- Group 1 · Strategy & Design (5): Functional Consultant, Solution Architect, Platform Architect, Process Designer, Integration Lead. Owns the requirement, design, dependency mapping, and the artifacts that go to design sign-off.
- Group 2 · Build (11): ITSM, ITOM, CSM, HRSD, SecOps Specialists, GRC Analyst, ServiceNow Developer, Scoped App Engineer, Flow Designer Specialist, IntegrationHub Engineer, Service Portal Developer.
- Group 3 · Quality (5): ATF Tester, Selenium Tester, QA Engineer, UAT Analyst, Performance Engineer. Generates ATF coverage in parallel with the build, runs Selenium for UI flows, assembles the per-story evidence package.
- Group 4 · Documentation & Compliance (5): Genewriter, GeneDocs, Compliance Advisor, Release Manager, Change Coordinator. Writes docs alongside the build, prepares change records, assembles the CAB-ready package.
- Group 5 · Operations & Knowledge (6 + Gene): CMDB Steward, Knowledge Curator, Evidence Collector, Self-Healing Agent, Dependency Mapper, Workspace Coordinator — plus Gene, the orchestrator that routes between groups, maintains MASTER_STATE, and enforces both sign-offs.
Agent Skill Chain. Every agent runs an identical internal chain — five sequential roles: Architect (system design & impact analysis) → Functional (user stories & acceptance criteria) → Coder (writes & executes SN code via REST) → ATF Tester (writes & runs ATF suites) → Selenium Tester (UI validation via browser automation).
The SDLC Pipeline
Every build runs through a six-stage continuous loop: Requirement → Design → Task Planner → Execute → SN Deploy → Verify. Each stage produces a discrete, auditable artifact. Two human sign-offs are non-negotiable.
- 1 · Requirement (Auto): The Requirement agent processes input — story brief, CSV, Visio, or plain English — into a structured, versioned Functional Requirements Spec, asking clarifying questions where the requirement is thin. Output: versioned spec (PDF). Sign-off: none.
- 2 · Design (Human Sign-off): The Design agent produces a full versioned Solution Design — data model, dependencies, ACL implications, integration shape, and exact Fluent artifacts, with an explicit "what I'm assuming" section. Impact Analysis (H1–H8) runs in parallel. Your architect signs off before anything is built. A named approver is recorded against every design.
- 3 · Task Planner (Auto): The Planner agent decomposes the approved design into a granular, ordered plan — every table, role, group, property, ACL, business rule, and test as its own task. Regenerate or adjust before a line is built. Output: ordered build plan (e.g. 28 tasks).
- 4 · Execute (Parallel): The Main agent builds tasks in parallel waves, writing real ServiceNow Fluent code (React + TypeScript) readable in the built-in IDE. ATF and functional tests are authored alongside; Genewriter writes technical docs; specialist agents step in for their artifact types. Sign-off: Medium risk shows a mid-build review prompt; High risk stops the build.
- 5 · SN Deploy (Reversible): Installs the scoped app as a safe, non-destructive update. Instance changes since your last deploy are merged in first; every step is checkpointed; the whole deploy is fully reversible. Never straight to production.
- 6 · Verify (Human Sign-off): Runs ATF (server + client) plus live-browser functional tests on GeneWorks' own runner (no ServiceNow ATF cloud-runner license). The Self-Healing agent repairs known-pattern failures; one-click Fix ATF / Fix FT handles the rest. The honesty principle applies — out of 100 stories, GeneWorks completed 73; here's a clean handoff for the remaining 27. Delivery lead reviews evidence and signs off before CAB.
Impact Analysis
An automated pre-build risk assessment across eight health dimensions, assigning a risk level before a single line of code is written. Impact Analysis is automatic and mandatory — every build request triggers it; results are presented before the Build stage begins.
| Area | Code | What Gets Assessed |
|---|---|---|
| Business Rules & Logic | H1 | Existing business rules that may conflict or be triggered — execution order, conditional logic, table interactions. |
| SLA Timers | H2 | Active SLA definitions whose timing/fields overlap. Changes to categorization, priority, or assignment fields are high-sensitivity. |
| Assignment Groups | H3 | Group configs, membership, and routing logic — skills, schedules, capacity. |
| Approval Workflows | H4 | Active workflow approvals and Flow Designer actions; open approval records that could be disrupted. |
| CMDB Records | H5 | CI relationships that may be affected, especially cmdb_ci hierarchy and relationship types. |
| Active Records | H6 | Live records (open incidents, active changes, in-flight requests) in scope — count and criticality. |
| Integration Points | H7 | Outbound REST, inbound scripted REST, IntegrationHub spokes touching affected tables/fields. |
| Security & ACLs | H8 | ACLs, roles, field-level security governing the change; flags access expansion/restriction. |
Risk Triage — LOW: all dimensions below threshold; build proceeds automatically after Stories approval. MEDIUM: one or more elevated; build pauses mid-execution for your review. HIGH: critical risk; build does not start — rescope or proceed with explicit authorization.
Update Sets
Update Sets are ServiceNow's native mechanism for packaging and transporting configuration changes between environments. Every GeneWorks build is delivered as a named, scoped Update Set.
Always Scoped — Never Default. GeneWorks creates and activates a dedicated Update Set for each task before any code is written, and never allows changes to land in the Default Update Set. This is enforced automatically and cannot be overridden.
Previewing and Committing — 1) In production, go to System Update Sets → Retrieved Update Sets, import from dev/UAT, and Preview. 2) Review preview results and resolve any flagged conflicts. 3) After CAB approval, Commit Update Set — all changes apply in a single audited transaction.
Rollback — Any Update Set can be backed out after commit (Retrieved Update Sets → Back Out Update Set). GeneWorks' audit trail preserves before/after state for rollback verification.
Writing Effective Prompts
Gene understands plain English — but prompt quality directly influences blueprint and build quality. The most effective prompts are specific about the outcome, name the target module or table, and include relevant constraints (timing, assignment groups, thresholds).
✅ Effective: mention the specific module; state the outcome, not the implementation; include business context (priority levels, SLA targets, group names); reference existing configurations Gene should know about. ❌ Vague: too brief ("Fix our incident routing"); no module context ("Set up some notifications"); ambiguous outcome ("Make things work better"); implementation-first ("Write a business rule on the incident table").
What Gene Returns
Every Chat response follows a structured format designed to give you actionable insight before committing to a build — a risk level, a blueprint summary, impact notes, and a proposed Update Set name.
Attaching Documents
Attach documents directly in Gene Chat to provide context that shapes the blueprint. Gene reads and indexes them in real time. Supported formats: PDF, DOCX, TXT, Markdown, HTML. Attachments are processed locally and indexed into your Knowledge Base.
- KB Articles — Attach ServiceNow KB exports or process docs to give Gene context about current configurations.
- Technical Design Docs — Upload TDDs from previous implementations; Gene extracts schema, table structures, and logic to inform the new blueprint.
- Existing Scripts — Share Business Rules, Script Includes, or background scripts; Gene analyzes them for dependencies and reuse before building anything new.
Documents attached in chat are automatically added to your Knowledge Base and indexed for all future sessions.
Chat History & Memory
Gene Chat history persists across sessions in the workspace and enriches future responses. The next time you ask, Gene already knows decisions you made three weeks ago, which assignment groups you use, and what you've built.
What gets remembered: module preferences, assignment group names, SLA thresholds you've defined, integration endpoints, naming conventions you prefer, past architectural trade-off decisions.
Brainstorm Mode
Brainstorm Mode switches Gene from execution to ideation — for exploring architecture options, mapping an ITSM strategy, or thinking through a complex integration before committing to a build. Gene maps the problem space, identifies solution patterns, surfaces dependency considerations, and presents multiple approaches with trade-off analysis. There is no SDLC pipeline in Brainstorm — it's pure architecture thinking.
Activate it by clicking the Brainstorm icon in Gene Chat, or by prefixing your message with "Brainstorm:". Export formats: Mind Map (SVG/PNG), Decision Matrix (CSV or table), and a formatted Solution Architecture document ready for stakeholder review or KB upload.
Task Pipeline
Let's Build is the execution interface. Where Gene Chat is for exploration, Let's Build is where requirements become ServiceNow artifacts. A task is the container for your requirement, its pipeline execution, all generated artifacts, and the delivery record.
Creating a Task
- 1 · Open Let's Build — See your task history and a prominent New Task button.
- 2 · Enter Title and Description — A concise title (e.g. "P1 Incident Escalation Notifications") and a detailed requirement. More context = better impact analysis and blueprint.
- 3 · Use Quick Prompts (Optional) — Pre-built templates: Add SLA Definition, Create Catalog Item, Configure Assignment Rules, Build REST Integration, and more.
- 4 · Attach Files (Optional) — TDDs, KB articles, existing scripts — indexed and used to enrich Impact Analysis and Blueprint.
- 5 · Start Pipeline — Gene begins the SDLC pipeline; the task workspace opens showing all six stage pills and the active stage.
Stage Walkthrough
- Design Stage — Shows the Functional Summary (plain-English of what Gene understood) and Dependency Analysis (objects in scope, H1–H8 flagged). If Gene misunderstood, edit the task description and restart before any code is written.
- Blueprint Stage — The full Technical Design Document — tables, fields, scripts, relationships, all SN object definitions. The proposed Update Set name is confirmed here; download the TDD as PDF.
- Stories Stage — Human Approval Gate: Lists all user stories with acceptance criteria. Read each, then click Approve Stories → Begin Build. You can reject individual stories or add comments first. Stories approval cannot be undone — review thoroughly before approving.
- Build Stage — A live execution log; Gene creates artifacts one by one via REST. Medium-risk builds show a review prompt at checkpoints; High-risk halts for explicit authorization.
- UAT Stage — ATF suite links, execution results, Selenium screenshots. Each test listed pass/fail; failures pause the stage with a diagnostic card.
- Completed Stage — Final delivery summary: Update Set name/location, artifacts created, ATF pass rate, notable findings, link to the full audit log. Your handoff record for production promotion.
Task History
Every task is preserved with its final status, completion date, Update Set name, and risk level. Clicking any task reopens its full workspace exactly as it was at completion.
Re-running stages: if a build failed mid-way, re-run individual stages; stage re-runs reuse the existing Blueprint and Stories unless you regenerate them. ATF tests can be re-run independently. Forking a task: duplicate any completed task as a new one — useful for building variations, starting with the same description and attachments.
ITSM Wizard
An 8-phase automated implementation path for greenfield ITSM deployments or major module rebuilds — from a blank instance to a fully configured, tested ITSM environment. Use it for net-new implementations, major rebuilds, or onboarding a new instance; for incremental changes, use Let's Build. Each phase must reach 80%+ completion before the next unlocks.
- 1 · Foundation — Update Set scoping; company profile; assignment groups & escalation paths; incident categories/subcategories; business-hours schedules; initial user import (CSV/LDAP); priority matrix (Impact × Urgency).
- 2 · SLA Management — P1–P4 SLA definitions (response & resolution); escalation at 50/75/100% breach; breach notifications; pause conditions; business-hours linkage; ATF suite for all SLAs.
- 3 · Service Catalog — Catalog structure; standard request items (hardware, software, access, facilities); approval workflows with cost thresholds; fulfillment task templates; variables/variable sets; order guides; ATF validation.
- 4 · Knowledge Management — KB records (IT, HR, custom); article templates; approval workflows (draft → review → published); subscription/notification rules; search config; retirement policy.
- 5 · User Provisioning — Bulk user import (CSV); role assignment rules; assignment-group membership automation; catalog entitlements by role; manager self-service access.
- 6 · Integrations — Inbound email → incident; notification templates; outbound webhooks (Slack/Teams/PagerDuty); LDAP/AD sync; third-party connectors (Jira, SCCM, monitoring).
- 7 · ATF Validation — Full suite across phases 1–6; incident lifecycle; SLA breach simulation; catalog submit → approval → fulfillment; KB create → approve → publish → search. 100% pass required before Phase 8.
- 8 · Go-Live Readiness — 40+ item checklist; handover package (Update Set manifest, TDD collection, ATF results, known issues); seeded KB articles; admin runbook; training outline.
Skip, Defer, Re-run. Any step can be skipped if it doesn't apply (logged in the completion record). Steps can be deferred to a later session (queued on return). Any completed step can be re-run, generating a new Update Set scoped to just that step.
ITOM Wizard
A 7-phase automated ITOM configuration path — from Discovery setup through CMDB governance, Service Mapping, Event Management, and optional Now Assist for ITOM. Prerequisites: the Discovery and Service Mapping plugins must be activated before Phases 2–4; Phase 1 verifies and halts with a remediation message if missing.
- 1 · Foundation & Scoping — Update Set; plugin verification (Discovery, Service Mapping, Event Mgmt); CMDB-focused H1–H8 impact analysis; credential store; IP scope (subnets, exclusions, scan windows); discovery schedule templates.
- 2 · Discovery Configuration — MID Server definition/verification; discovery schedules with IP ranges & credentials; probes & sensors (horizontal, port scan, classification); CI class mapping & reconciliation; first supervised run; log analysis.
- 3 · CMDB Health & Governance — Health dashboard review (staleness, completeness, duplicates); IRE rules; duplicate-CI conflict resolution; class hierarchy extension; relationship rules; governance policies (owners, review schedules).
- 4 · Service Mapping — Business Service records; mapping patterns (entry points, traffic); top-down/bottom-up strategy; run execution & graph validation; manual relationship overrides; service health scorecards.
- 5 · Event Management — Event source connectors (SNMP, REST, email, monitoring); alert correlation (dedup, storm suppression, root cause); alert-to-incident rules; maintenance windows; operator workspace.
- 6 · Now Assist for ITOM (optional) — Feature activation; AI alert-correlation tuning; natural-language CI search; CMDB health recommendations with one-click remediation; operator AI assistant.
- 7 · Go-Live Checklist — CMDB completeness assessment; discovery schedule verification; service mapping validation; event runbook; operator training guide; full Update Set manifest & handover.
Platform Administration
The Platform Admin Agent handles the operational health of your instance: licenses, access control, user governance, performance, and the system audit trail. Coverage: license auditing & optimization, ACL & security review, user access management, performance monitoring & tuning, plugin health. Produces: audit reports with remediation recommendations, ACL gap analysis with risk scoring, over-provisioned user lists, performance baseline/anomaly reports, and Update Sets for remediation.
License Auditing
Scans license allocation vs. usage — total seats vs. active users, last-login timestamps, role-to-license alignment, inactive accounts consuming paid seats, over-provisioned fulfiller licenses. Reports a utilization table, estimated savings from reclaiming seats, and a recommended action list (deactivate, downgrade, reassign). Gene generates an Update Set for approved remediations — you commit.
ACL Review
Scans all table-, record-, and field-level ACLs against ServiceNow's recommended baselines; detects wildcard ACLs and circumventable role conditions. Findings are presented as a risk-scored gap table — High (potential breach), Medium (policy violation), Low (best-practice deviation) — with plain-English risk and a specific remediation. Gene can generate ACL correction records as an Update Set, all logged with before/after configs.
User Access Management
Detects over-provisioning, admin sprawl, and dormant accounts. Over-provisioned roles: admin/security_admin holders with no admin actions in 90 days are flagged. Inactive seats: accounts with no login within a configurable threshold (default 90 days), with last login, roles, and groups. Admin sprawl: admin-access count vs. your defined ratio policy.
Performance Monitoring
Evaluates slow queries, high-frequency business rules, client-script execution times, Scheduled Job backlog, Import Set times, and table growth.
| Issue Type | Gene Can Fix | Action |
|---|---|---|
| Duplicate Business Rules | ✓ | Merges and deactivates duplicates |
| Unoptimized Script Conditions | ✓ | Rewrites condition logic |
| Slow Database Queries | Reports | Recommends index additions (DBA action) |
| Scheduled Job Conflicts | ✓ | Adjusts run schedules |
| Table Growth Anomalies | Reports | Recommends archiving policy |
| Client Script Performance | ✓ | Optimizes DOM query patterns |
Integration Agent
The Integration Agent builds, tests, and packages integrations between ServiceNow and external systems, supporting all major patterns with secure credential handling.
| Pattern | Direction | Best For |
|---|---|---|
| Outbound REST | ServiceNow → External | Pushing SN events to external tools (Slack, Jira, PagerDuty) |
| Inbound REST (Scripted API) | External → ServiceNow | Creating/updating SN records from external systems (alerts → incidents) |
| IntegrationHub Spoke | Bi-directional | Complex workflows using Flow Designer actions |
| Webhook (Event-driven) | Bi-directional | Real-time event push without polling (GitHub, payment webhooks) |
| Email Actions | Inbound email | Creating/updating records via email (email-to-incident) |
Common examples: SCCM → CMDB (CI population), Slack → Incident (slash command), Email → Incident (inbound mailbox), Jira ↔ Change (bidirectional sync of status, comments, assignee).
REST Integration Example
Building a Jira → ServiceNow incident integration: 1) Describe it ("When a Jira issue is created with label 'sn-incident', create a P2 incident assigned to IT Operations"). 2) Gene routes to the Integration Agent (Inbound REST from Jira webhook). 3) The blueprint defines endpoint path, payload schema, field mappings, error handling, auth. 4) Gene creates the Scripted REST API, Resource, and processing script. 5) Gene sends a test payload and verifies the incident.
Authentication & Credentials
All major auth methods are supported; credential handling is strictly local — credentials never transmitted to GeneWorks servers.
| Auth Method | How Gene Handles It | Stored In |
|---|---|---|
| Basic Auth | Creates a ServiceNow Credential record; never plain text | SN Credential Store (encrypted) |
| OAuth 2.0 | Configures OAuth Provider record & JWT; guides you through the flow | ServiceNow OAuth registry |
| API Key / Bearer Token | Creates a Credential record; uses it in REST Message headers | SN Credential Store (encrypted) |
Knowledge & Learning
GeneWorks' agents are trained across the entire ServiceNow knowledge surface, retrieve from an embeddings store, repair their own failures, and learn from a lessons-learned file — so they get more reliable the longer they run on your instance.
Training Corpus
| Source | What it teaches |
|---|---|
| Product documentation | Platform capabilities, table schemas, APIs, configuration patterns |
| Upgrade & release notes | What changes between releases, deprecations, new features |
| Product fixes & known errors | Common defects and the correct ways around them |
| YouTube transcripts | Practical, demonstrated implementation techniques |
| Community notes & forums | Real-world edge cases and field-tested solutions |
| Partner-portal methodologies | Delivery best practices and implementation standards |
| Support documentation | Troubleshooting and supportable configuration guidance |
| GeneWorks delivery IP | Proprietary patterns and accelerators from real engagements |
An embeddings store retrieves the most relevant knowledge for each task. Combined with the persistent workspace — your instance's history, conventions, and prior decisions — the agents get faster and more accurate the more they work on your instance.
Self-Healing
When a build or test fails on a recognized pattern, the agents repair and re-run it automatically — the same one-click Fix ATF / Fix FT in Verify. A failure is matched against learned patterns; where a known fix applies, the agent corrects and re-runs; where it doesn't, the item is flagged for a human — nothing is silently marked "passed." Each repair feeds the lessons-learned file, so the longer GeneWorks runs, the fewer failures reach a human.
Lessons Learned
The agents write every mistake to a lessons-learned file they read before acting. What gets recorded: failed approaches (and the fix that worked), instance-specific gotchas, review feedback from sign-offs, self-healing corrections, and reusable patterns. Relevant lessons are retrieved semantically — by meaning, not exact keywords — and applied before the agent acts.
Governance & Security
GeneWorks is built around human-controlled, AI-accelerated execution. Governance is not an afterthought — it is the architecture.
Human-in-the-Loop Framework
| Trigger | HITL Action | What You See |
|---|---|---|
| Design stage completion | Required design sign-off | Design card with Approve/Reject. Build does not start until a named human approves. |
| Verify completion | Required verification sign-off | Evidence package with Approve/Reject. Nothing promotes to CAB until reviewed. |
| Medium risk Impact Analysis | Mid-build review prompt | Build pauses at checkpoint. Confirm to continue or stop. |
| High risk Impact Analysis | Full stop — escalation | Build does not begin. Full impact report shown. Rescope or authorize explicitly. |
| ATF test failure | UAT stage pause | Failed tests with diagnostics. Review and remediate before proceeding. |
| Production instance detected | Connection blocked | Connection test fails with explicit message. No override available. |
What GeneWorks Can and Cannot Do
| Capability | Can Do | Cannot Do |
|---|---|---|
| ServiceNow artifacts | Create/update/delete in dev/UAT | Modify production instance |
| Update Sets | Create, name, scope, manage | Commit to production (your action) |
| Credentials | Store locally in SN Credential Store | Transmit credentials externally |
| Users | Provision/update in dev/UAT | Modify production user accounts |
| ATF | Write and execute test suites | Mark tests passed if they fail |
| HITL | — | Human sign-offs cannot be bypassed |
Credential Security
Local-first, zero-transmission. ServiceNow credentials entered in Settings are stored encrypted on your local machine and used only to authenticate REST calls from your local GeneWorks instance to ServiceNow — never sent to GeneWorks servers. Integration credentials (OAuth tokens, API keys, Basic Auth) are created as records in ServiceNow's native encrypted Credential Store; Gene creates the record but never reads back the secret. Knowledge data (embeddings store, lessons-learned) resides in your local GeneWorks data directory.
Audit Trail
Every GeneWorks action is logged in a structured, tamper-evident audit trail — the authoritative record of what was built, when, by which agent, at what risk level, and the before/after state. Every entry includes the entity (the SN object created/modified/deleted), an ISO 8601 timestamp, the responsible agent, the risk level, and the before/after state.
Reference
Supported Releases: Yokohama, Xanadu, Washington DC (fully supported); Vancouver (partial — core ITSM & Platform Admin, limited ITOM); Utah & older (not supported — upgrade to Washington or later).
Artifact types span the High/Medium/Lower fit tiers documented on the Platform Capabilities page — from Service Catalog items, Notifications, Client Scripts, and UI Policies (high fit) through Business Rules, Script Includes, and Transform Maps (medium) to multi-component orchestrations and Mobile Studio (lower).