I build FORMLOVA, a chat-first form service. The entry point is an MCP server: you describe a form in an AI chat, and the agent builds it, publishes it, and runs it. But this post is not really about my product. It is about something I noticed about the shape of my own work, and I think it is going to happen to a lot of builders whether they planned for it or not.
Here is the noticing, in one sentence. For years, my attention was the glue holding my acquisition tools together -- and for eight days, it stopped having to be.
I run my own ads and my own forms. I am the one who builds the form, builds the ad, watches each of them, and lines the numbers up by hand. Nobody feels that scatter more directly than the person who is personally carrying it. So when I set out to run the whole loop from a single chat, I was not testing a thesis. I was testing whether the most tedious part of my own week -- the part where I am the integration -- could just go away.
Think about what it takes to acquire a single user through a paid channel. You build a form. You build an ad. You manage the form. You manage the ad. You analyze the result. That is five distinct jobs, and on a normal day each one lives in a different tool, behind a different login, with a different layout I half-remember.
Closing the loop means moving between all of them. I build the form in one place. I set up the ad somewhere else. When the numbers come in, I read the ad metrics on one screen, then open the form admin on another, then line the two up in my head -- or worse, in a spreadsheet -- to figure out whether a click actually became something real. I am the integration. My attention is the glue holding five tools together.
That has always just been the cost of doing acquisition solo. You absorb the tab-switching because there is no other way. The tools do not know about each other.
What I tested over eight days is whether that is still true.
The shift is not "now there is an AI button in my dashboard." It is more basic than that, and I felt it in my hands. MCP -- the protocol an AI client uses to connect safely to an outside service -- means an agent can hold several services open in the same conversation at once.
So the ad side exposes an MCP. The form side exposes an MCP. Both are reachable from the same chat. And the moment that is true, the five jobs stop being five places I have to visit. They become five things I can ask for in one thread, without the loop ever leaving the conversation -- and without me copying a single number between two screens.
This is the part I want to be precise about, because it is easy to wave at. I am not saying the agent magically does acquisition for me. The jobs are still real jobs, and the judgment is still mine. What changed is where my hands go. The surface I work on went from five to one, and the thing that used to hold those five together -- my own attention, dragged across tabs all day -- was no longer the load-bearing part.
That is a small macro instance of a bigger thing I have written about elsewhere: software shifting from something you open to something an agent calls. The fuller argument is here. I will not re-litigate it in this post. I only want to show you what it felt like at the bench, with money actually moving.
I kept the spend small on purpose -- ¥6,597 over eight days. The point was not to win at ads. The point was to see how much of the loop I could keep inside one conversation.
Almost all of it, it turned out.
I pulled the ad metrics in chat with a plain request. The baseline numbers came back: 704 clicks, a CTR of 12.62 percent. On the surface those read well -- a high click-through rate for an ad meant to gather sign-ups, at a cheap cost per click. The kind of numbers you screenshot and feel good about.
Then, in the same chat, I switched to the form side. The form-side data breaks responses down by ad ID, so I can ask which ad a response came from without leaving the thread. And here is where having both sides in one conversation earns its keep: acquisition cost is just spend divided by the conversion count, and I can derive it right there in chat by pulling the spend from one side and the count from the other. Neither tool can do that alone. The ad side ends at "clicks came in." The form side ends at "responses arrived." Only the two together, in the same turn, close the gap.
I charted the eight-day trend without opening a dashboard. And when the trend looked a little off, I went looking for why.
The cheap, high-CTR clicks were a mirage.
When I split the delivery by placement, the skew was obvious. Roughly 96 percent of impressions and about 83 percent of spend had gone to Audience Network -- the in-app slots, not the feeds I had actually meant to reach. Audience Network is where near-mistap clicks are common, which is exactly why a flattering CTR can come out of it while barely putting the ad in front of anyone on the feeds I cared about. The efficiency numbers looked great. The destination was not what I assumed.
What matters for this post is what I did next. Because the problem became visible inside the conversation, the fix happened inside the same conversation. I rebuilt the ad set -- limited to the feeds, Audience Network excluded -- and each of those operations was reversible. I did not open the ad manager to do it. Read the metrics, find the problem, act on it, all in one thread.
That is the whole point. Not that the campaign was a triumph -- it taught me my targeting was pointed at the wrong surface. The point is that diagnosing it and correcting it did not require me to become the glue between five tools again. The loop stayed in one place.
Let me be careful about what I am claiming, because it is narrower and more durable than a growth-hack headline.
I am not claiming an agent does my marketing. I am not claiming the result was good -- the first delivery skewed to the wrong placements, and I have follow-up work I will be honest about: firming up the measurement parameters on the ad URL, confirming the outcome event is received cleanly, and the bigger question of whether this channel even fits this product.
What I am claiming is that the seam between the jobs dissolved. Build, launch, collect, analyze, fix -- five things that used to be five tools with me carrying numbers between them -- ran as one continuous conversation. The round-trip of reopening dashboards, reapplying filters, copying a figure into a spreadsheet, that round-trip is the thing that went away.
And I think this is the part builders should sit with. We have all internalized the tab-switching as a permanent tax on solo operations. It is not permanent. It is an artifact of tools that could not talk to each other. As more of the surfaces you already use start exposing MCP, the cost structure of your own workflows quietly changes underneath you. The work does not get easier because someone automated it. It gets easier because it stops being scattered.
If you are a small team or a team of one, you feel the scatter more than anyone. A big company can throw a person at each tool. You cannot. You are the one holding the glue, and the glue is your attention, which is the scarcest thing you have.
So running the whole loop from one chat is not a convenience feature for builders. It is a different distribution of where your attention goes. Less of it spent navigating between screens, more of it spent on the actual judgment -- is this channel right, is this targeting pointed at real people, is a cheap click actually worth anything.
I did not set out to prove a thesis with eight days and a small budget. I set out to see how much of my own loop I could keep in one place, and the answer surprised me by how much. I came away thinking less about my campaign and more about the shape of the work. The shape is changing. The tools are starting to meet in the conversation instead of making me meet them, one tab at a time.
That is the build log. Not a victory lap -- a note from my own bench. For eight days I ran the whole loop without leaving the chat, and I felt the floor move under a real budget, with the unflattering numbers left in. I went in as the glue between five tools. I came out not having to be.
The full proof -- the measured field report this post is grounded in, with the numbers and the placement breakdown laid out honestly -- is here:
And if you want the broader picture of what it means to run a form service that does not stop at building, but operates after publishing:
This is a FORMLOVA founder build log. The author is the developer of FORMLOVA. The ad metrics, the placement skew, and the form-side breakdown are first-party figures measured inside a single chat in a real AI client over the eight days from May 21 to May 28, 2026, moving between an ad-side MCP and FORMLOVA's MCP. Numbers may move over time. Acquisition cost is described as a capability -- spend divided by the form-side conversion count, derivable in chat -- and the specific figures beyond those quoted live in the linked field report.
This is a strong build log, especially because you are not pretending the campaign itself was the win.
The useful part is the workflow collapse: form creation, ad setup, response tracking, spend comparison, and correction all happening in one place.
I do think the positioning could be simpler though. Right now the post explains the system deeply, but the buyer promise is slightly buried.
The sharper angle might be:
“Build the form, run the campaign, and see which ad actually produced responses without leaving chat.”
That makes FORMLOVA feel less like an MCP form service and more like an acquisition workflow layer for solo builders.
For early users, I’d probably target founders already running small paid experiments, not generic form users. They will feel the pain much faster because they already care about matching clicks, spend, and real outcomes.