Today we’re launching Phyllis.
Phyllis is an agentic developer and implementation team for ServiceNow. It plans, develops, monitors, manages, and deploys against your instance — with an approval gate on every change. It was built by a team that has lived inside the platform for a decade, with both CMA and CTA certification in the room, because a tool that writes to ServiceNow has to be judged the way a senior architect would judge it.
This post is the long version of what we shipped, why we shipped it, and what it changes for the people on the other side of the screen.
The problem we keep seeing
Platform teams are drowning, and the backlog is the proof. Every ServiceNow customer we’ve worked with has the same shape of list: dozens of half-scoped intakes, a handful of “in-flight” builds that have been in-flight for quarters, and a small mountain of governance work — documentation, scan cleanup, ATF gaps, scope drift — that nobody ever gets to.
The industry’s answer for ten years has been “more bodies.” More consultants. More offshore capacity. More fast-tracks. It doesn’t work, because the bottleneck isn’t one role or one stage — it’s the whole loop. Planning takes weeks because discovery starts from a blank page. Feature uptake stalls because no one has time to read the release notes against the live instance. Development is slow because the mechanical build is hand-wired one record at a time. Governance is the last thing to land because the documentation, the scan, and the test pack are written after the fact, if at all. The work compounds, and so does the backlog.
Phyllis is a developer accelerant. It runs alongside your team across every part of that loop — the discovery, the build, the scan, the documentation, and the upgrade analysis, all against your live instance — and stages the result behind a governance gate your senior architects still own.
How Phyllis drives value
Value in ServiceNow delivery is not mysterious. It comes from four places, and Phyllis targets each one:
- Throughput. The number of changes a platform team can ship in a quarter, without lowering the bar on quality. Phyllis accelerates your developers — absorbing the mechanical build, the scoping document, the Instance Scan pre-flight, and the ATF attach — so each story arrives at architect review with the design doc and the evidence already attached, and architects spend their day on the architecture calls and governance decisions only they can make.
- Quality at the gate. A change is only valuable if it survives review and production. Phyllis runs Instance Scan against the update set (or the full instance) before review, surfaces findings with severity and owner, and — on approval — stages the fix in an update set for the architect to sign off. The architect sees the diff, the scan, and the ATF result in the same place.
- Audit evidence. Most governance failure is not bad intent. It is missing evidence at the moment it was needed. Phyllis writes the CMA-grade design document alongside the update set, with every source cited back to the instance record it came from. The engagement closes with evidence, not assurance.
- Delivery cost. On every fixed-price engagement, on every internal build, the unit economics of ServiceNow work change when discovery, build, scan, and documentation happen in one loop instead of four meetings.
The pattern across all four is the same: Phyllis does not replace the person who signs the change. It compresses the distance between intent and reviewable output, and it raises the floor on what “reviewable” means.
End-to-end implementations, not AI snippets
Phyllis is not an autocomplete bolted onto Studio. It is an implementation loop that covers the full arc of a change.
- Discovery. Phyllis reads the target instance — tables, flows, business rules, ACLs, scopes — and inventories what’s already there before the first workshop. Discovery starts where the instance actually is, not from a blank page.
- Plan. Scope, dependencies, sprint sizing. Every plan arrives with stories, cross-module links, and acceptance criteria written against the real system.
- Build. AI Agents, flows, catalog items, business rules, ACLs — all assembled into a named update set. Scoped, tagged, and attributed, so your architects can follow every record back to the intent.
- Monitor. 83 scan definitions ship out of the box — across upgradeability, performance, security, user experience, and maintainability — to keep the instance healthy and aligned to best practice. Phyllis also monitors every build: every dev task ends with a scan. The difference is Phyllis can self-heal. Run scans ad hoc against an update set or the full instance, and on approval Phyllis stages the fix for the architect to sign off.
- Manage. ServiceNow releases, patches, plugin changes. Phyllis reads the release notes, maps impact against the instance, and hands the team a digest they can act on.
- Deploy. Preview runs, collision resolution, re-preview, and a staged update set ready to commit. No black-box deploys — every step is visible, every action is reviewable.
The point of stitching these together is not novelty. It’s that the cost of context-switching between tools is where most delivery friction actually lives. One loop, one composer, one approval gate.
What this does to the development backlog
The most visible thing Phyllis changes in the first month is the shape of the backlog.
The long tail — the items that have been “on the list” for a year because they were too small to staff and too scoped-in to ignore — starts moving. Scan findings that were logged and deferred become staged update sets waiting for review. Documentation gaps get filled in alongside the code they describe. Scope cleanup, naming drift, orphaned records, silent ATF failures — the un-glamorous governance work that gates audit readiness — gets picked up in the background.
Then the next thing happens: your senior architects get faster. Not because they’re doing more, but because every change arriving at their desk lands with the diff, the scan report, the ATF run, and the design document already attached. Governance becomes a judgment call on the architecture, not a scavenger hunt for evidence.
Over a quarter, the shape of the backlog changes from “a list of intents waiting for builders” to “a queue of reviewable changes waiting for judgment.” That is the shift we care about.
What every persona gets on day one
Phyllis is not a single-seat tool. It changes the day-to-day for everyone adjacent to a ServiceNow delivery, and it has to earn its place with each of them.
Platform teams and ServiceNow developers. The composer that does the boring parts. Build against the real instance, not a blank page. Generate the update set, the stories, the sprint sizing, the scan attach, and the ATF wiring in one loop. Spend your day on the architecture calls you got into this work to make — not the thirtieth variant of a catalog item.
Senior architects (CMA / CTA). A governance gate you actually own. Every story arrives at your desk with the diff, the Instance Scan result, the ATF run, and a CMA-grade design document in the same record — every claim cited back to the source it came from. You sign work you can see, with evidence you can cite. Governance stops being a scavenger hunt for the design rationale that never made it into the story, and starts being the architecture judgment your team needs you to make.
Platform owners and ServiceNow product leads. A backlog that moves, and a governance posture that improves at the same time. Scan findings close instead of accumulating. Documentation lands with the code. Audit prep stops being a quarterly scramble because the evidence has already been written.
MSPs and implementation partners. Fixed-price engagements that actually pencil. Read the customer’s instance before the scoping call. Hand them a staged update set and a scoping document in hours. Deliver the CMA-grade handover as the default state of every engagement, not the heroic exception. Run more customer engagements in parallel without more senior capacity.
Enterprise buyers and PMO. A unit of work that is legible. The same record holds the design, the scan, the test, the update set, and the sign-off. Compliance, change advisory, and internal audit all look at the same artifact — and it is the same artifact your reviewer already approved.
Transformation sponsors and CIOs. A delivery function that scales without linearly scaling headcount, and an answer to the “where’s the AI story in our platform?” question that is not a demo — it is the actual way the team ships on Monday morning.
What we are not
We are careful about what Phyllis is, because the AI-for-enterprise space is full of things that are not what they say on the label.
- We do not ship changes without an approval gate. Your architect signs every update set.
- We do not replace the senior architect. We give them leverage, and we give them better evidence.
- We do not scan across instances in real time. Scans are on-demand — update set or full instance — when you want them.
- We do not integrate with everything under the sun on day one. We integrate with the places ServiceNow delivery actually happens, and we add from there based on where real teams ship.
The pitch is not “AI will do your job.” The pitch is: Phyllis is a developer accelerant — your team ships materially more change in the same week, and your senior architects govern that change with the design document, the Instance Scan, and the ATF results already in front of them. The senior judgment that ServiceNow delivery depends on stays where it belongs.
What’s next
If you run a platform team, an MSP practice, or a ServiceNow program — and you want to see Phyllis against a real instance instead of a slide — book a session. We walk end-to-end: update set, Instance Scan, ATF, design document. You bring the intent. We bring the instance work.
This is the launch. The real story starts when the first change lands in your architect’s queue with everything it needs already attached.
— Regan
w.
