AI here is a row in your marketing database, not a tab in someone's browser
HeadshotMarketing models an AI tool as a workspace object and every generation as a costed execution record behind the same permission gate as the rest of the app. That architecture is real today. The live model behind it, the spend ceiling around it, and the overnight decision loop on top of it are not — and this page says which is which.
Most marketing suites bolt a chat panel onto a CRUD app and call it intelligent. HeadshotMarketing was built the other way round: the objects an AI needs in order to be governable came first. An AI tool is a workspace record — a category, a provider, a model, a configuration, an enabled flag and a usage count — curated and shared like a campaign template rather than retyped into a chat window. Running one produces an execution record that exists before the work starts, moves through RUNNING to COMPLETED or FAILED, and stores the input, the output, the token count derived from the actual text, the wall-clock duration, the computed cost and the actor who ran it. A failed run is kept with its error message and the time it burned. That is the difference between AI you can audit and AI that merely happened somewhere.
The second structural decision was to put the AI inside the marketing graph rather than beside it. Campaigns and templates, content items and assets, contacts, leads, deals and pipelines, social accounts and posts, ad campaigns, creatives and audiences, influencers, events, SEO keywords and audits, landing pages and recorded channel performance all live in one federated subgraph, and every field on it carries an authorization directive the gateway enforces from the composed schema. So a generated caption saves as a real content item, tagged ai-generated with the tool and model recorded on it. An audit writes a real audit row with real findings. The external agent surface and the in-app console call the same operations the screens call. There is no second authorization path for an agent to slip through, and no separate AI datastore to reconcile with the truth.
What we will not claim. Generation is deterministic and runs inside the product: every output is a pure function of your input and the tool you picked, which makes it fast, private and repeatable — and means it is not a frontier model. The engine sits behind a single function so a governed provider call can replace it without touching the console, the ledger or the drafts. AI runs are measured but not yet capped: the execute mutation carries no platform quota directive, so there is no hard spend ceiling the way there is on active campaigns and contacts. The lead score is a live field with a live distribution chart and no engine behind it. The overnight optimization loop is designed and deliberately sequenced behind a shared multi-model runtime that has not shipped, because thirty-seven products each wiring their own provider keys and run ledger would be a governance liability, not a differentiator. HeadshotMarketing is pre-launch, and nothing here describes customer results.
Every capability on this page is labelled with what is actually built in HeadshotMarketing today — shipped, in progress, or on the roadmap.
AI-native by architecture, not bolted on
Four architectural choices that make AI a first-class part of HeadshotMarketing rather than a chat window on the side.
An AI tool is a record, not a prompt in a chat
Category, provider, model, configuration, enabled flag and usage count, stored per workspace and shared across the team — so the recipe that worked is curatable and re-runnable instead of trapped in one person's chat history.
Every run lands in a ledger you can query
The execution row is created before the work starts and completed with tokens, duration, cost and the actor. Failures are retained with their error and elapsed time. AI usage is metered and attributable like any other action.
The AI calls the same operations your screens do
Authorization is declared on the schema and enforced once at the gateway. The console, the assistant and the external agent surface all inherit the caller's role — there is no privileged AI path and no service that re-implements auth.
One subgraph, so AI reads and writes the real rows
Campaigns, content, CRM, ads, influencers, events, SEO and recorded performance are one federated domain. Generated copy becomes a tagged content item; an audit becomes an audit row. Nothing lives in a side database.
From intent to a governed action
Walk the path a request takes. Select any stage to see what happens there and what backs it.
Stage 1 of 5 · Context
Workspace state, not a blank prompt
The console opens with your tools, your recent runs and this month's usage already on screen.
One bootstrap query loads the tool catalog, the executions feed and the per-tool monthly counts, so the console is usable the moment it renders and auto-selects the first enabled tool. The tool you choose sets the input mode — a prompt box for copy, a page URL for SEO — and the model options available. The floating assistant is mounted at shell level, so it is reachable from every authenticated page rather than one route. This is also the thinnest link in the chain today: the assistant transport passes the product identifier and credit posture and nothing else, so the agent knows which product you are in, not which campaign you are looking at.
How it works: microfe-headshotmarketing/src/services/createSandboxAssistantTransport.ts calls fe-libs useSandboxAssistantTransport({ product: 'headshotmarketing', enableCredits: true }) with no gatherPageContext callback; AIToolsPage.tsx derives its tool grid, model options and month-scoped counts from the shared bootstrap query
What the AI in HeadshotMarketing actually does
Filter by delivery status, then open any capability for the detail and what backs it. No capability is listed as shipped without something in the product behind it.
Where the AI shows up
The places AI meets the work in HeadshotMarketing — and how far each one has actually got.
AI console
ShippedA two-pane content workshop inside the marketing app: a workspace library of tools on the left, a docked generation panel on the right, and a run history under both.
- Tool grid shows category and uses-this-month per tool; disabled tools read Coming soon rather than failing
- Input mode follows the tool — a prompt box for copy, a page URL for SEO work
- Output arrives in the format's own shape, with variants, extracted keywords and suggestions
- Copy, or Save as draft to write a real content item tagged ai-generated
- Footer reports the run's duration and token count; generation is deterministic, not a live model call
See it as a real scenario
Every AI capability above shows up in a concrete HeadshotMarketing story. Open one to read the full walk-through.
Spin up on-brand content with a library of AI tools
Register reusable, purpose-built tools in the workspace, run them on demand, and keep every run as a tracked execution — a governed content workshop rather than scattered prompts.
Read the storyDraft every marketing format from one console
Nine formats, each returned in the shape that channel needs — subject-line variants, ad headline and CTA, caption plus hashtags, outline plus intro — with keywords and suggestions attached.
Read the storySee exactly what your AI usage cost
Tokens, duration and cost on every run, month-scoped totals in the console, and an ai-generated tag on everything that came out of it. Enforcement of a spend ceiling is still owed.
Read the storyAudit a live page and get the ranked fix list
Fetch the real HTML, score it four ways, and rank every finding with its recommendation — then generate the missing meta tags next door and re-run to confirm.
Read the storyPoint your own AI agent at the marketing stack
Roughly 172 typed tools over campaigns, CRM, content, ads, SEO and analytics through one authenticated MCP server, inheriting your role — with unconfirmed deletes flagged honestly.
Read the storyGet a conversational AI marketing partner
A floating assistant for strategy, drafting, segmentation and reading your analytics, mounted on every page and running on the shared platform agent runtime.
Read the storyScore leads on behaviour — and show the working
The score column, the tiers and the distribution chart are live in the CRM today; the engine that derives them, and the explanation of every movement, is the roadmap.
Read the storyLet a scheduled agent propose the budget shift
Read overnight performance, rank concrete reallocations with the evidence attached, and stop at a human approval gate. Designed, sequenced behind the shared runtime, not running.
Read the storyAI you can actually let near your data
An AI-native product has to be governable. Here is where HeadshotMarketing stands on each control — including the parts still being built.
AI data never leaves the workspace boundary
Tools, executions, generated drafts and audits are workspace-scoped rows, and the isolation is enforced in the database as well as in the query layer by a row-level-security migration covering the product tables. Cross-workspace access fails as not-found because the workspace filter is part of the primary query, not a check bolted on afterwards.
Authorization enforced once, at the gateway
Every AI query and mutation declares its action, resource and scope on the schema, and the workspace gateway enforces it from the composed supergraph. Services never validate tokens. The console, the assistant and the external agent surface all call the same operations, so an agent cannot reach anything its user could not.
Every run is inspectable after the fact
The execution record keeps the input, the output, the status, the actor and the timing — including for failures, which retain their error message and elapsed time. Drafts created from a generation carry an ai-generated tag plus the tool, provider and model, so months later it is still possible to ask which assets started as AI output and which run produced them.
The one outbound fetch is guarded
Auditing a user-supplied URL is a server-side request forgery risk by default, so the guard lives in the engine rather than in a policy document: only public HTTP and HTTPS URLs are fetched, and loopback, RFC1918, link-local, unique-local, .internal and .local hosts are rejected before any request is made.
Cost is measured per run — but not yet capped
Tokens are counted from the actual text, duration is wall-clock, and cost is derived and stored on the run. What is missing is enforcement: the execute mutation carries no platform quota directive, so nothing rejects a runaway caller the way the platform already caps active campaigns, contacts, landing pages and connected social accounts. Declaring that quota is committed work, and it matters more once anything runs on a schedule.
Evaluation sets and destructive-action confirmation
Two honest absences. There is no evaluation harness for generated copy, so quality improvements cannot yet be demonstrated as regression-tested claims rather than opinions. And on the external agent surface, delete-class tools accept no confirmation argument, so an agent acting on an ambiguous instruction can remove a record in one call. Both are named here rather than glossed, and gating destructive operations is the first item of that work.
Models
HeadshotMarketing does not pick, pin or resell a model, and will not imply otherwise. Content generation today runs on a deterministic engine inside the marketing service: every output is a pure function of your input and the tool you selected, with token counts computed from the actual text and a derived cost stored on the run. That makes it fast, private and repeatable — and it is emphatically not a frontier model. The tool record carries free-text provider and model fields, and the console builds its model dropdown from those strings, but choosing one records a label in the run's metadata; it does not route to a provider. There is no provider SDK, no API key and no model catalog in this service, deliberately: a shared multi-model gateway with a model catalog and a run ledger is a platform capability that has not shipped, and thirty-seven products each wiring their own provider keys would multiply the audit surface rather than the value. Bring-your-own-key is therefore not available. The floating assistant is the one surface backed by a real agent runtime — the platform's shared sandbox agent, with credit accounting on — and even there the provider is a platform concern, not a HeadshotMarketing one. When the shared runtime lands, this product will render its model picker rather than build one, and the generation engine will become the documented fallback when a provider call fails.
The honest answers
Not today, and we would rather say so than let you assume it. Generation runs on a deterministic engine inside the marketing service: it dispatches on the tool you picked, extracts frequency-ranked keywords from your input, and returns copy in that format's structure with real token and cost accounting. Every output is a pure function of your input and the tool, which is why it is fast, private and repeatable. It is also why it is not a frontier model. The engine is isolated behind a single function that the console, the ledger and the draft path already call, so a governed provider call can replace it without changing any of them — that swap is the next step, not a shipped claim.
Put HeadshotMarketing’s AI to work
HeadshotMarketing models an AI tool as a workspace object and every generation as a costed execution record behind the same permission gate as the rest of the app. That architecture is real today. The live model behind it, the spend ceiling around it, and the overnight decision loop on top of it are not — and this page says which is which.