AI-Agent-Driven Client Strategy Project Creation Automation: From a Chat Request to 25 Modules Filling In the Background

Building a strategy-creation flow around a real, logged-in user session is a reasonable starting point — it's how the product's own wizard and its own chat-based bulk-fill both work. The gap only becomes visible the first time someone reasonably expects an internal AI agent, not a person clicking through the UI, to be able to do the same thing on request. An agent has no browser session to inherit, so a capability built exclusively around one doesn't just work worse for an agent — it doesn't exist for one at all, and the only way to find that out is to actually ask for it and watch the request go nowhere.

An endpoint built for a person's own authenticated browser session assumes a set of things that don't hold for a server-to-server caller: it expects a real user's session token, not a shared internal secret; it assumes whoever is asking already has a legitimate reason to be looking at that specific client, because the UI itself only shows clients the logged-in user can see; and it has no reason to guard against being triggered twice in quick succession, because a person clicking a button twice by accident is a rare, low-stakes event compared to an automated caller that might retry on a whim. Every one of those assumptions has to become an explicit, coded check the moment the same action becomes reachable from outside a browser session — organization membership has to be verified explicitly, and a job already running has to be detected and left alone rather than duplicated.

The gap was surfaced by a direct, real request, not a planning exercise: an owner asked the internal team chat who had access to Vesper, then asked that person's agent to create every client's strategy inside it. The agent that received the follow-up request discovered, by trying, that no agent anywhere in the network had a single write tool onto Vesper — the request came back explicitly blocked, and a portfolio-wide check found 11 of 18 active clients with no strategy project in Vesper at all.

The fix adds one new internal route to Vesper itself, authenticated by a shared secret header rather than a user session — the same pattern the platform already uses for other internal, service-to-service calls, with the fallback debug token used elsewhere in development. Without that secret configured on the server, the route doesn't function at all rather than falling open. The route verifies the requested client actually belongs to the calling organization before touching anything, then either reuses the client's existing active strategy project or creates a new one, deriving a starting cycle objective from whatever the client already has on record when none is explicitly given. Whichever path it takes, it dispatches the fill job through the exact same background engine Vesper's own chat-based bulk-fill already calls — so the actual work of populating 25 strategy modules (ICP, personas, positioning, customer journey, growth plan, and more) runs through one single, already-proven code path regardless of whether a person or an agent triggered it, rather than a second implementation that would need to be kept in sync forever.

The corresponding agent-facing tool is deliberately narrow about who can use it: the migration restricts it to roles that plausibly own client strategy — strategy, account, direction, and a dedicated internal specialist role — and explicitly not the security role that had wrongly claimed Vesper access in the original incident. It accepts up to twelve client names in one call, resolves each by a case-insensitive partial match against the organization's own active clients, and refuses to guess when a name matches more than one client rather than picking one arbitrarily. Because the fill itself takes minutes and runs in the background, the tool's own returned guidance is explicit that the calling agent must never describe the strategy as finished the moment the tool returns — it should report that the work was dispatched, for which clients, and point to a separate, paired read-only tool to check real completion status afterward.

Someone asks an agent to set up strategy for a list of clients, several of whom already have a project with some modules filled from a previous run. The creation tool doesn't restart any of them from zero — an existing active project is reused, and only the modules still marked incomplete are queued for filling, alongside genuinely new projects created for whichever names on the list had none at all.

A client no longer needs someone to manually open Vesper and click through a wizard for a strategy project to exist — a portfolio-wide sweep can be dispatched from the same conversational surface already used for everything else, restricted to the roles that should reasonably be doing it, and always reusing the one real fill engine rather than a second one built just for this path. And because the tool is explicit that dispatching is not the same as finishing, nobody managing the agent has to guess whether a background job that takes minutes actually completed — a dedicated status check exists specifically to answer that.

A team wanting an agent to write the actual strategic content itself — deciding positioning, ICP, or growth plan from scratch with no human review — will not find that here: this automation creates the container and dispatches the same structured-input engine the product already uses, not a freestanding strategist. A team that wants every strategy creation gated through a specific human approval step before any module starts filling should route that approval before calling the agent tool, since the tool itself creates and dispatches immediately once a valid client and role are confirmed.

A capability that only exists behind a logged-in browser session is invisible to anything that isn't a person clicking through a UI — including an internal agent asked to do the exact same job in bulk. Centriu's approach keeps the one real underlying engine untouched and adds a second, role-gated front door onto it authenticated for machine callers, rather than either rebuilding the engine a second time or leaving agents permanently unable to trigger something a person can already do in the product.