The Hardest Part of Building AI Isn't the First Customer. It's the Next Hundred.
What does it take to scale enterprise AI? See how BlueConic turned real customer feedback into a more scalable, accessible AI Canvas.


There's a particular challenge in building AI-powered software: making something work for one customer is very different from making it useful for hundreds.
A successful demo can show what's possible. A hands-on implementation can prove that something works. But neither necessarily tells you what it takes to make that capability useful across different customers, teams, and workflows.
That's something we've been learning firsthand at BlueConic.
Key takeaways
- Scaling AI takes more than a successful implementation. The real challenge is turning lessons from individual customers into capabilities that work for many.
- Real-world usage reveals what AI products actually need. Customer feedback shaped AI Canvas improvements in scalability, flexibility, data access, and user control.
- BlueConic is bringing AI Canvas to its broader CDP customer base. Customers can now use AI agents to build audiences, configure behavioral listeners, and set up supported connections.
When we first introduced AI Canvas back in April this year, my team of forward-deployed builders worked directly alongside customers to turn its capabilities into useful outcomes. They combined technical expertise with an understanding of what each customer wanted to achieve, staying involved as the work moved from an initial idea into implementation and adoption. That closeness helped customers make progress and showed us where the product needed to improve.
Now, as we prepare to make AI Canvas and Design Agents available directly to our broader CDP customer base, I've been reflecting on what that experience has taught us about building AI that can scale.
Why Forward-Deploy Building Matters
Forward-deployed engineering has become a much more prominent part of the conversation around enterprise AI. The idea is straightforward: put technically experienced builders close to the people using the technology, rather than relying entirely on requirements documents and handoffs.
For me, there's something familiar about that approach.
I've been with BlueConic since the beginning. When we started building what would eventually become our customer data platform, we didn't have an established category or playbook. We had a handful of customers, a clear problem we wanted to solve, and a lot of questions.
We worked closely with those customers, watched what worked, and changed what didn't. The distance between a customer problem and the people who could solve it was incredibly short.
As the company grew, we gained the structure and specialization needed to scale. But we also introduced more distance between the people using the product and the people building it.
Our forward-deployed builder team is, in many ways, an effort to recover that closeness without giving up the advantages of scale.
Every Implementation Should Teach You Something
When you're working directly alongside customers, you see things that are difficult to anticipate in a product planning meeting. You learn how people actually approach a task, where they need guidance, and which parts of a workflow are more complicated than they initially appear.
That was an important part of our approach to AI Canvas.
Rather than treating each implementation as a project to complete and move on from, we treated it as an opportunity to learn. Our builders stayed close to the work, helping customers put capabilities into practice while bringing what they observed back into product development.
But there's a distinction that matters here: we weren't trying to become a custom development team.
Solving an individual customer's problem is valuable. Recognizing that the same underlying problem exists across many customers, and finding a way to solve it more broadly, is how you build a product. That requires judgment. Not every request should become a feature, and not every successful implementation represents a repeatable use case. The challenge is identifying the patterns worth building around, so that what you learn from one customer makes the experience better for the next.
What We Learned
Four lessons came up again and again across our implementations. Each one changed how we built AI Canvas.
Build for scale. Demos run on tidy setups. Real customer environments rarely look like that: many have grown over years and carry complex configurations with countless interconnected objects. A canvas that is easy to read with ten objects becomes hard to use with two hundred. So we added grouping, letting customers collapse and expand related objects to see the whole picture or focus on one part of it.
Build for flexibility. Let customers define success. Every customer wants to know whether what they’ve built is working, but they don’t all define “working” the same way. We started with one standard way of tracking results and attributing success and learned that it didn’t fit everyone. So we gave customers more room to measure what matters to them, while keeping the experience simple enough to understand at a glance.
Build for real data, not for schemas. A data schema tells an agent that a field exists. It doesn't tell the agent what's in it, how it's filled, or which values matter. For agents to build useful segments, they need access to the customer's real data, so that's what we gave them.
Build for trust. Early on, when an agent updated or deleted existing configuration, there was little feedback or prompting to let the user know. In a live environment, customers need more visibility than that. So we built guardrails into AI Canvas: agents can create and iterate freely, but need explicit user approval before changing or deleting existing configuration. Customers stay in control of what they already have.
Each of these improvements helped make AI Canvas more useful in practice. But our builders’ responsibility extended beyond getting something built. It also meant helping customers understand how it fitted into their workflow, how to measure whether it was working, and how to keep using it. A working implementation was an important milestone; the goal was for customers to get value from it.
Staying involved through adoption helped our builders find these patterns: problems that first appeared in one customer’s implementation and revealed something we could make easier for others.
Scaling What Works
This November marks another important milestone for AI Canvas: making it easier for our existing CDP customers to put its capabilities to work. AI Canvas and Design Agents are now available directly within their BlueConic environments, helping marketers with everyday tasks like building audiences, configuring behavioral listeners, and setting up supported connections.
For me, this milestone reflects the work we've been doing since April, when our forward-deployed builders began working alongside customers to put AI Canvas into practice. Those hands-on implementations helped us understand what customers need to use AI effectively in their own environments. And what we learned has helped us make those capabilities more accessible, so more customers can start exploring and using them independently.
Of course, broader access doesn't mean the learning is finished.
As more customers use AI Canvas across different environments and workflows, we'll encounter new questions, new use cases, and challenges we haven't anticipated. That feedback will be just as important to what we build next.
There's a principle we've carried forward from BlueConic's earliest days: stay close to the customer, learn quickly, and turn what works into something others can benefit from.
For our forward-deployed builders, that means staying close enough to understand the problem, helping customers turn an idea into something useful, and carrying what we learn into the next solution. Each engagement should deliver value for the customer in front of us—and help the next customer get there faster.
Frequently asked questions
What is BlueConic AI Canvas?
BlueConic AI Canvas is an agentic workspace that helps marketers work with their customer data platform using specialized AI agents. It simplifies tasks such as building customer audiences, configuring behavioral listeners, and setting up supported connections.
What are BlueConic Design Agents?
Design Agents are AI agents within BlueConic that help users configure customer data platform capabilities. They can work with real customer data to build useful audiences and assist with other configuration tasks, with user approval required before modifying or deleting existing configurations.
How did customer feedback shape BlueConic AI Canvas?
BlueConic worked directly with customers through its forward-deployed builder program to identify common challenges. That feedback informed improvements to organization, outcome measurement flexibility, agent access to real data, and safeguards for existing configurations.
What is forward-deployed engineering in enterprise AI?
Forward-deployed engineering places technical builders alongside customers to solve real-world problems, support adoption, and bring implementation insights back into product development. The goal is to turn lessons from individual engagements into capabilities that benefit a broader customer base.

