.webp)
Table of Contents
Key takeaways
Successful implementations are all about extracting knowledge from the people who know what the software needs to do, and getting it to the people who know how to make that happen.
Back in April 2026, we started building a methodology for AI driven Pigment implementations. Through iterative work with customers across the world, we have formalized it into Stencil.
For customers and partners who’d like to know more about how it works, I’ll outline here each step of the process, the technology used, the guardrails in place, and the learnings we’ve taken so far.
How does it work?
Stencil makes use of a team of 7 agents, each with specialized skills, harnessing the power of the Claude Code LLM harness.
Each agent represents a role in a project team: project manager, solution architect, modeler, tester, admin, and two agents dedicated for the continuous improvement of the Stencil.
They guide the humans using the tool on the recommended process, our Stencil methodology, empowering them throughout.
Note: The modeler agent within the Stencil acts as a ‘wrapper’ of the in-platform Modeler Agent, which communicates with Pigment via the MCP.
The process
Onboarding
This is the first step of any customer implementation. At this stage, we establish:
- Customer readiness level - this will determine how fast the process can proceed (more details of this later on)
- Project scope
- Roles and responsibilities
- Governance and escalation process
- Timeline and milestones
- Project management tools to be used
- Official communication channel
This part of the process may look similar to a non-Stencil implementation.
What’s different is that we feed all of the information captured above, including information captured during discovery in the sales cycle, into project memory accessible to all the agents that will work on the implementation.
Design
Then comes the design phase. At this point we conduct design workshops with the customer to capture exactly what they need Pigment to do for them. The output of these workshops (transcripts, notes, Excel files, screenshots, and other collateral) are all fed into Stencil, which produces:
- A design document, which records what each Application must do, for whom, and with what data. The customer validates it, and it is the reference point for every scope discussion that follows.
- A solution architecture document, which shows how the Applications fit together, built on Pigment's best practices for scale and performance.
- User stories, which capture specifically what each user needs from an Application: for example a cost center planner might need to see headcount roster and the associated salary cost.
With these in place, we can start designing the end user interface.
Frames has completely transformed this stage of the process - previously, wireframes looked dramatically different to the end product (often produced in Excel), took much longer to produce, and weren’t functional. This meant it was harder for customers to understand how the final product would actually work, and led to more iteration when the boards were ultimately built.
The flexibility and speed afforded by this new process means we’re able to iterate on the board and frame design before the build phase, which is amazing.
Build
At this point, we’re ready to start building. The build phase is actually three in one: spec, build, eval.
First, each user story is translated into a detailed spec: a granular build plan to produce the desired functionality in Pigment.
These are then executed by a Modeler Agent (either via MCP or in Pigment). The Modeler Agent has skills,which contain a library of best practices that ensure optimal functionality and performance.
And then to ensure it’s working as intended, each spec has a matching eval that’s designed to test that it worked, using synthetic data where necessary.
Example spec
Once a user story is passing eval, it’s time for a human steer from the implementation team. Is this working as intended? In the example above, it might be that we notice that not every planner should see salary data.
We add a new spec (to limit salary visibility for example) and run the agentic process again - once we’re happy, this user story is approved.
Not only does Stencil accelerate the build phase dramatically, it also offers the benefit of consistency. When the same agents build every Application in a multi-use case project, they apply the same build philosophy, which makes moving between them easier for implementers and customers.
Test
Now it’s time to test what we’ve built with customer stakeholders. To make this part of the process faster, a Stencil agent drafts UAT (user acceptance testing) scenarios using the design document and spec, organized by use case.
If further revisions to the Application(s) are required, we can then make those changes.
Launch
At this stage, we hand over the Application to the customer. But they get much more than they did before: extensive documentation of every decision made, the rationale behind it, and any other context that may be helpful in the future.
Packaging the project memory like this has a few benefits.
First, it’s much easier for a customer to make changes themselves in the future, without needing to reengage. Second, it serves as a rationale register, recording why certain decisions were made during the build. Finally, it can feed a custom agent, or wider company knowledge base that can help business users understand how the Application works.
The bottom line
Based on results so far and customer readiness, Stencil is delivering results 2-7x faster than before.
“Operationally, it meant Finance could go into a leadership or investor conversation with a live, drivable model rather than a static deck, months earlier than a standard 9-to-12 month implementation would have allowed.”
Raymond Yue, SVP of Finance, Avalara
Hear more about Avalara’s implementation →
In the next article, we’ll explore what the process might look like a year from now.
Try Pigment for yourself at https://www.pigment.com/trial/sign-up.
