Skip to main content
Start with the work you want done. A marketer can give an authorized assistant a goal and guide the workflow in Apostra. A developer can build software that chooses when and how to call its tools. A team can also bring business data in and read results out without putting a model in the loop. “Managed” here means using Apostra’s supported product workflows. It does not mean you can upload arbitrary software and have Apostra host its runtime. A custom application or external agent owns its own scheduling, retries, and long-running workflow state today.

​
Keep business decisions separate from transaction state

For a hybrid application, keep your customer’s request, approval records, workflow checkpoints, and Apostra object IDs in your application’s durable store. Let Apostra own the saved campaign, creative, media buy, and delivery facts. Re-read those objects when resuming instead of treating a model’s prior answer as their current state. An agent can propose a budget or choose among returned offers. Your application decides whether that recommendation is within policy and who must approve it. Apostra still applies account permissions, seller readiness, creative review, funding, and transaction checks. Passing your application’s approval does not skip those checks. This division works for a small loop that reads data and recommends an action, and for a larger application that also manages creative production or external business systems. Add those responsibilities when your product needs them; they do not require a different Apostra campaign model.

​
Choose MCP or REST for each job

The transport does not decide who owns the loop. Code can be an MCP client, and an agent can call REST through application tools. Prefer MCP when discovery and model-facing schemas help; prefer REST when direct HTTP requests fit the job. MCP OAuth credentials are bound to their endpoint. A token issued for /mcp/v3 cannot be reused on REST or another MCP endpoint. See Authentication before combining surfaces.

​
Decide whether the software needs its own identity

A coding agent using a person’s OAuth connection acts in that authorized session. It does not need to be registered as a buyer agent. An application integration also does not automatically need a separate buyer-agent identity. Register an external buyer agent when software needs its own credentials, advertiser grants, lifecycle, and machine notifications. An administrator uses the buyer-agent management flow to establish those separately. Registration alone grants no advertiser access or spending authority. Hosted-agent creation is not currently available through the public v3 catalog. Continue with Connect in five minutes, then Build an agent or Build a reporting pipeline.