I moved from building an AI agent marketplace to a marketing automation product. Here’s what changed.
I originally built CAIt as an AI agent marketplace.
The idea was that users could order work from AI agents, keep delivery history, use approvals, and move from conversation to execution without needing expert prompts.
Technically, I still like that idea.
But as a product, I struggled with one thing: it was too broad.
When a product can be used for many workflows, the hardest part is not building features. It is helping a specific customer understand why they should change their current process today.
While building CAIt, I kept seeing the same pattern. The useful parts were not just the agents. The useful parts were the workflow around the agents:
- keeping context visible
- turning conversations into actions
- reviewing before publishing
- saving delivery history
- measuring what happened after execution
That pushed me toward MASAMUNE.
Instead of building a general AI agent marketplace, I started focusing on one painful workflow: marketing automation for B2B SaaS teams.
The CAIt lessons still shape MASAMUNE:
- Context matters more than prompts.
- Approval flows are not optional for real business use.
- AI output is only useful if it connects to execution.
- Measurement needs to be part of the workflow, not an afterthought.
- A narrower product is easier to explain, build, and improve.
The hardest part was accepting that “more flexible” was not always better. MASAMUNE is less general than CAIt, but that is the point. It is designed around a clearer job: helping teams move from research and planning to execution, review, and measurement.
For other founders here: have you ever rebuilt a broad product into a narrower one? What did you keep, and what did you throw away?
Full disclosure: I'm Avery Lin (avrlin). I've been packaging a Paid Skill Fulfill Engine ($29 — Stripe/x402 verify → email/return the zip) with AI assistance, so take this as adjacent interest, not neutral advice.
Biggest leak I keep seeing on agent marketplace delivery / paid skills: buyer pays for a skill pack or zip, then someone still hand-DMs the download. A small fulfill layer (Stripe webhook sig verify or x402 settle → idempotent email/return bytes) closes payment→file-sent without babysitting every order.
Curious — when you were on the agent marketplace side, was payment→delivery already wired end to end, or did fulfillment still need a manual handoff?
The list of what made the agent marketplace actually useful is the most insightful part of this. Context visibility, approval flows, delivery history, execution connected to measurement. Those aren't nice-to-haves, they're what make AI output usable in a real business context rather than a demo. The problem with general AI marketplaces isn't the agents. It's that there's no workflow structure holding the agents to a standard. Each agent does its own thing in isolation, there's no shared memory of what was decided before, no governance over what the agent is allowed to do, and no way to trace why a decision was made. When you went narrow, the workflow constraints you added almost certainly did more for quality and reliability than any improvement to the underlying model. Have you found that the narrower workflow forces teams to define their requirements more clearly before they start? That's usually the hidden benefit of discipline around scope, it catches the vague briefs that would have produced bad output regardless of how smart the AI was.
Nice breakdown — I agree completely. In my experience the biggest benefit of narrowing scope is forcing requirements to be explicit up front, which prevents most bad outputs. A practical pre-run checklist I use:
That discipline catches vague briefs, speeds iteration, and makes attribution possible. If you want, I can paste a one-page template or a small flow example we’ve used in the wild.
One thing I'd be curious about:
How much of the simplification happened in the product itself versus in the way the product is explained?
Reading this, I can still see many of the same underlying ideas.
The thing that seems to have changed most is where you're choosing to start the conversation.
That’s a good read.
I’d say both changed, but the explanation changed first.
A lot of the underlying ideas are still there: agents, context, approvals, execution history, and measurement. I did not completely throw those away.
What changed was the starting point.
With CAIt, I was starting the conversation from the system architecture: “AI agents can do many kinds of work.”
With MASAMUNE, I’m starting from a specific user problem: “A B2B SaaS team needs to move from marketing research and planning to execution, review, and measurement.”
That forced product simplification too. Instead of exposing a broad agent marketplace, MASAMUNE makes stronger assumptions about the workflow. The product is less open-ended, but easier to understand and easier to use for the first job.
So the biggest lesson for me was: the product can keep similar primitives, but the entry point has to be much narrower.
That's the part I'd be most curious about.
A narrower entry point definitely makes the product easier to understand.
I'm less certain it automatically makes the decision easier for a buyer.
Those aren't always the same thing.
What's interesting is that the primitives you're describing still sound capable of supporting a much broader ambition underneath.
I agree with that distinction.
A narrower entry point makes the product easier to understand, but it does not automatically make the buying decision easier.
That was one of the hardest lessons from CAIt. The underlying primitives were powerful enough to support many workflows, but I had a hard time explaining the user benefit in a concrete way.
For a buyer, “AI agents can help with many kinds of work” is interesting, but it still leaves too much work for them:
With MASAMUNE, I am trying to keep the broader primitives underneath, but make the first benefit easier to understand: helping a marketing team move from research and planning to execution, review, and measurement without stitching everything together manually.
So I don’t see the narrower entry point as the full ambition. I see it as the wedge. The broader system can still exist underneath, but the first use case has to be specific enough that the buyer does not have to assemble the product in their head.
That's exactly why I found it interesting.
A lot of products use a narrow use case as a wedge.
Fewer end up becoming the broader thing they originally envisioned.
The point where those two paths start diverging is probably more interesting than the wedge itself.
I've got a few thoughts on that, but it's probably more than I'd try to unpack properly in a thread.
What's the best email to reach you on?
That’s a really interesting framing.
I agree that the divergence point is probably the more important question than the wedge itself. I’d be very interested to hear your thoughts.
You can reach me at: support@masamune.online
Appreciate it.
Just sent you an email.
The divergence point ended up feeling more interesting to me than the wedge itself.