Magic Agent Platform
The agent platform Magic’s own operations run on.
Orchestration, instruction governance, and context assembly. Live with two paying customers, in production internally for two years. Available to design partners.
Start a conversationThe agent infrastructure available in the market is either a toolkit you assemble yourself — dozens of components, no governance, your data inside a hyperscaler — or a vertical product handling one use case and nothing else. Neither works for a mid-market organisation that needs production-grade commercial agents running on infrastructure they actually control. We built the Magic Agent Platform for Magic's own operations, proved it on two live customers, and are now offering it to a small number of companies who want the same discipline applied to their own internal commercial life.
Three disciplines.
Most agent platforms handle one. Some handle two. The Magic Agent Platform handles all three.
Orchestration.
Which agent runs, when, on what data, with what authority. Every automated action is condition-checked at execution time. If the premise is no longer true, the action self-cancels with a documented reason rather than firing on stale context.
Instruction governance.
What the agent is allowed to say, in whose voice, under whose authority. Structural prompts (reasoning framework, output format) are versioned separately from dynamic knowledge (product data, entity context). Magic's reasoning evolves independently of each customer's data.
Context assembly.
What the agent knows at the moment of reasoning. Per-request context from entity data, performance history, interaction timeline, and aggregate patterns. Assembled at constant token cost through materialised views. Recommendations grounded in the customer's reality and broader patterns simultaneously.
Identity is the root, not the wrapper.
Every agent platform has access controls. Magic is different: identity is the architectural primitive that every other capability is built on. The agent knows who it is talking to before it decides what to say, what to do, and what to reveal.
Passwordless, cryptographic, everywhere.
Every person, organisation, and agent in the Magic ecosystem authenticates through cryptographic identity. No passwords. No credentials to rotate. No attack surface from credential reuse. The same identity works across the community AI, the operations chat, the campaign engine, and the commerce attribution layer — one identity, verified once, trusted everywhere.
The same agent, different behaviour, enforced in code.
A community’s Magic Agent serves three tiers — admin, member, public — from the same interface. What changes is not the agent but what the agent is allowed to know and do. Member-only content is filtered at the server level before the AI model sees it. An organisation’s operations chat gates actions by trust level — who can approve a pitch, activate a campaign, view analytics. The boundaries are architectural. They do not depend on the model following instructions correctly.
Know your agent.
As organisations deploy AI agents that send emails, answer questions, and make commitments on their behalf, the question of agent identity becomes a trust question. Who authorised this agent? What are its boundaries? Who governs what it says? Every Magic Agent carries a verifiable identity tied to the organisation that controls it — the same cryptographic infrastructure that authenticates members and leadership. When an agent acts, the identity of the organisation behind it is provable. In a landscape of anonymous AI, that provenance is the difference between trust and liability.
Everything that varies between customers clusters into exactly seven dimensions.
Everything outside these seven is shared infrastructure that transfers directly.
Domain vocabulary.
What the organisation calls its entities and stages. Stored in Config, read by all systems.
Email transport.
Gmail, Microsoft 365, or SMTP. A unified send function routes by transport type.
Selling motion.
Step count, cadence, channels, personalisation depth. Lives in the data, not in the code.
Product catalogue structure.
Tab name, column layout, grouping logic. A loader function abstracts the specifics.
Team structure and trust levels.
Who can approve, log, view, create. Stored in configuration, enforced in code.
Brand.
Colours, fonts, logo, tagline. CSS variables in frontends, string interpolation in emails.
Identity and hosting.
Subdomain, Magic Agent identity, Automation runtime, governed data store. Each customer gets their own isolated instance.
Five layers, one codebase, many customers.
Config object.
One configuration surface defining everything customer-specific.
Template sheet.
Pre-built tabs, correct headers, empty rows. Cloned per customer.
Codebase.
One codebase, reads from Config, operates generically. No customer-specific logic.
Prompt library.
Structural templates (Magic's IP) plus domain injections (customer's data).
Customer onboarding.
Rapid deployment for communities. Scoped onboarding for organisations.
What a design partnership offers.
Direct working relationships with the team that builds the platform. Milestone-based engagements with preferential pricing. Not self-serve.
Start a conversation.
If this is the shape of what you want to build on, tell us what you have in mind.
Contact usinfo@magic-id.com
We respect your privacy
We only use one cookie to remember your language preference. We don't use tracking cookies. No analytics, no tracking, no data collection — just a better experience for you.