For most of last year, when someone asked me what SocioLogic does, I'd say something like: "We build AI-powered synthetic personas for market research. You can interview them like real people and get insights fast."
It was a clean pitch. People understood it. Some people even got excited about it.
But it was the wrong framing. And it took us longer than I'd like to admit to figure out why.
The "Research Tool" Trap
When you position yourself as "an AI market research tool," you get compared to other market research tools. SurveyMonkey, Qualtrics, UserTesting, Dovetail. You end up in conversations about sample sizes and statistical validity and whether synthetic responses are "as good as" real ones.
These are reasonable conversations! But they box you in. You're competing on the merits of a single use case, and the buyers are people with "research" in their title and "research tools" in their budget.
Meanwhile, the most interesting things people were doing with our personas had nothing to do with traditional market research. A developer was using personas to test whether error messages made sense to non-technical users. A content team was running blog post drafts past personas representing their audience segments. A founder was "interviewing" personas to pressure-test a pivot before talking to real customers.
None of these people thought of themselves as doing market research. They were querying agents.
The Reframe
The shift happened when we started building our MCP server (Signal Relay). We were exposing our persona capabilities as MCP tools so that AI assistants like OpenClaw could call them directly. And as I was writing the tool descriptions, I realized: a persona is just an agent that responds to queries with a specific behavioral profile.
That's it. It's not a "research platform." It's an agent you can talk to.
And if it's an agent, then it belongs in the same infrastructure as every other agent. It should be discoverable through the same registry. It should be callable through the same protocol. It should be payable through the same payment rails.
This sounds like a minor architectural observation, but it changed everything about how we think about the product.
What Changes When Personas Are Agents
They compose with other agents
When a persona is just an MCP tool, it can be chained into workflows. An agent can scrape a competitor's website, feed the content to a persona agent, and ask "would this messaging make you switch?" That's not a research session. That's a pipeline. And the persona is one node in it.
We've seen users build workflows like: gather data > synthesize into brief > query persona > generate report. The persona step is no more special than the data gathering step. It's just another tool in the chain.
They don't need a dedicated UI
This was a hard pill for me to swallow as a product person. I'd spent months designing our interview interface. It had conversation threading, persona switching, insight tagging, export options. It was nice.
But most of our power users were hitting the API directly, or calling personas through their AI assistant. They didn't want our UI. They wanted the capability, accessible from wherever they were already working.
When your product is an agent in a network, the UI is whatever the user's orchestration layer happens to be. For OpenClaw users, it's their chat interface. For developers, it's their code. For automation builders, it's their workflow tool. Our job isn't to build the best interview UI. Our job is to build the best persona agent.
Pricing aligns naturally
When we were a "research tool," pricing was awkward. Monthly subscriptions? Per-project fees? Seat-based licensing? Every model felt wrong because usage patterns varied wildly. Some users ran hundreds of persona queries a day. Others ran a handful per month.
As an agent, the pricing model is obvious: pay per query via x402 micropayments. You call the persona, you pay for the call. Light users pay little. Heavy users pay more. No subscriptions, no commitments, no sales calls. The protocol handles payment at the request level.
It's simpler for us, but it's also simpler for the user's agent. An AI assistant calling our persona tool doesn't need to authenticate with an API key tied to a billing account. It can pay per request, autonomously, the same way it pays for any other x402 service.
Discovery becomes automatic
In the "research tool" world, users discover you through Google searches, product review sites, or word of mouth. In the agent world, discovery happens through the registry. An agent that needs persona research capabilities can find us the same way it finds a web scraping service or a payment processor: by querying the verified agent registry for services matching its needs.
We publish our agent card at a .well-known path. It describes what our personas can do, what inputs they expect, what they cost per query. An AI agent can read that card and decide whether to use us without a human ever visiting our website.
What This Framing Gets You
The "AI research tool" framing caps your market at people who buy research tools. The "agent in a network" framing opens it up to anyone building with AI agents. That's a bigger audience, and it's growing.
But the bigger point is about composability. A standalone research tool is useful for research. A persona agent in a network is useful for anything someone can think to plug it into. And people think of things you'd never predict.
One user built a "customer empathy bot" for their support team that queries our personas before suggesting responses. Another built a content calendar generator that runs each topic idea past persona agents representing different audience segments and scores them by predicted engagement. A third uses personas in a hiring pipeline to test whether job descriptions are clear to the target candidate profile.
None of these use cases appeared on our roadmap. They emerged because personas were agents in a network, and people connected them to things we didn't anticipate.
The Uncomfortable Part
I should be honest about what we lost in this transition. The "research tool" positioning was easier to explain. It had a clear buyer persona (ironic, I know). It fit into existing budget categories. It was a product that marketing could put on a landing page with a feature comparison table.
"We're an agent in a network" is harder to pitch. People want to know what you do, specifically. "I'm a node in an infrastructure graph" doesn't close deals.
We're still figuring out the go-to-market for this. The product is clearer than it's ever been. The story is still catching up. If you're going through a similar reframe, I'd love to compare notes.
But I'm convinced the framing is right. Personas aren't a product category. They're a capability. And capabilities belong in networks.