AI-Agent Campaign Brief Creation and Generation Handoff Automation: From a Chat Message to a Structured Brief, Nothing Spent

An internal specialist agent that can describe a client's campaigns but can't start a new one is useful for a status check and frustrating for the actual job it was hired to help with — someone still has to open the app, fill in a form, and kick off generation by hand every single time a new campaign needs to exist. The natural next step is letting the conversation itself create the starting point. The risk in that next step is exactly as obvious: a chat agent that can create things needs the same discipline about budgets, platforms, and approval that the human-facing app already enforces — arguably more, since nobody is looking over its shoulder in real time the way a person filling out a form gets a second look before submitting.

An endpoint built to receive a person's own authenticated request from the app's own frontend makes assumptions that don't hold for an internal agent calling on someone's behalf: it expects a user's own JWT, not a service account's; it has no reason to validate a platform name against a fixed list if the app's own dropdown already only offers valid options; and it has no reason to demand a real, specific budget if the app's form has a required field enforcing that already. Every one of those implicit assumptions has to become an explicit check the moment the same capability is offered through a conversation instead of a form — because a chat message can say anything, including "radio" as a platform or nothing at all where a budget belongs.

The starting state, recorded directly in the migration's own header, was blunt: the agent's 8 existing Maestro tools were all read-only, plus one action for responding to an optimization recommendation — there was no path to actually create anything. The owner's own instruction, quoted directly in the same header, set the bar: campaigns the agent helps create need to be genuinely high quality, with no room for one to simply go wrong.

The brief-creation tool validates before it ever writes a row. The platform argument is checked against a fixed list — meta, google, linkedin, tiktok, gmb — with common synonyms normalized first ("facebook" and "instagram" both resolve to "meta," "google ads" resolves to "google"), and anything else is rejected with a message naming the valid options rather than a generic error. A business objective and a target audience are both required as real text, not placeholders. The budget is required as a positive number, and the tool's own instructions to the agent state the rule explicitly: never guess a budget — if the owner didn't say one, ask. A budget type (daily or lifetime, accepting Portuguese synonyms too) rounds out the required fields. Once created, the brief comes back with the client's configured ad account for that platform when one exists — and when one doesn't, the response carries an explicit warning that the campaign can still be generated and approved, but won't be publishable until an ad account is registered, surfacing the gap immediately instead of at publish time.

The generation-handoff tool takes a brief ID and calls the exact same AI generation engine Maestro's own app interface already uses — the pillar's existing page on that engine describes what it does with a structured brief in detail, and this page doesn't repeat that; what's new here is how the request reaches it. Because the calling agent has no user session to present, the generation endpoint gained a second, service-to-service authentication path: a shared internal secret header (the same pattern already used for the platform's other internal-to-internal calls) paired with the target user's ID in the request body, resolved specifically to the organization's own owner — read directly in the code, every check that already applied to a person's own request (rate limiting, confirming the brief actually belongs to that user, the plan's AI generation quota) still applies to this resolved identity. Nothing about calling through the agent grants an exemption from any of those limits. The response Maestro gives back is explicit that the resulting campaign is "awaiting approval," and the tool's own instructions tell the agent never to describe it as "published" — publishing to the real ad platform remains a separate, human action inside the app.

The migration proves its own claims rather than merely asserting them: an embedded block, executed at migration time against a real client account, creates a real brief, confirms the ad-account field came back populated (as expected for a client with one on file), confirms a zero-budget attempt is rejected, confirms an invalid platform ("radio") is rejected, confirms the new brief actually appears in the listing tool's output, and then deletes the test brief it created.

Someone asks the media-buying specialist agent to set up a campaign on "insta" for a client. The tool normalizes that to the correct platform code rather than rejecting a common shorthand — but if someone instead names a platform the generation engine genuinely doesn't support, the brief-creation tool rejects it immediately with the actual list of valid options, rather than allowing a brief to be created that would only fail later when handed to generation.

A campaign can start from a conversation instead of requiring someone to open the app and fill in a form from scratch — while every guardrail the form itself would have enforced (a real platform, a real objective and audience, a real budget, awareness of a missing ad account) is enforced just as strictly in the chat path. And because the resulting campaign is always born awaiting approval, starting a campaign through the agent never becomes a shortcut around the human decision to actually spend money.

A team hoping the agent will publish a generated campaign directly to Meta, Google, LinkedIn or TikTok will not find that here — generation only ever produces something awaiting approval, and publishing remains a separate, human, in-app action regardless of how the campaign was generated. A team hoping the agent will estimate or suggest a budget on its own will find the opposite: the tool requires a real number and is explicitly instructed to ask rather than guess.

A web form enforces its rules by construction — a dropdown only offers valid platforms, a required-field marker stops an empty budget from submitting. None of that protection exists for a free-text conversation unless it's rebuilt explicitly. Centriu's approach makes every one of those implicit form guarantees an explicit, testable check in the tool itself — platform validated against a real list, budget required and never guessed, a missing ad account surfaced immediately — so that opening the capability to a conversational agent doesn't mean lowering the bar the app's own form already enforced.