Platform
Autonomy without a blank cheque
Xyranik is three layers. A growth OS that understands a business and decides what to do about a goal. A trust layer that governs every action before it happens. And the agent infrastructure both of them run on — which the agents you build can use too, on a credential of their own.
- 01Growth OS
Understands, decides, executes, measures, learns.
- 02Agent trust layer
Decides whether an action is allowed, before it happens.
- 03Infrastructure
The API, tools, webhooks and metering underneath.
Layer one
Growth OS
What a business actually interacts with: it learns the business, decides what is worth doing, runs the work you approve, and measures what came of it.
Business BrainWhat it knows about you, and where each fact came from
Most software that claims to understand your business is really pattern-matching your industry. Business Brain is the opposite: it is a record of your business specifically, assembled from your own website and your own orders, where every fact can be traced back to the sentence it came from and corrected by you when it is wrong.
AI CMOThe strategy, with every claim sourced
The ordinary way to get a strategy out of a language model is to describe your business and ask. What comes back is fluent and unfalsifiable. Xyranik does it the other way round: it assembles the evidence first, from your own records, and then holds the answer to it.
AI workforceAgents defined by what they may do
A prompt is a request. An agent that can be talked out of its instructions was never constrained by them. In Xyranik every limit an agent has is enforced by the runtime: what it may read, what it may propose, how much risk it may ask for, and how sensitive the data it handles may be.
GoalsA goal it can actually measure, or it says so
The quiet failure in goal-tracking software is a progress bar over a number nobody is really measuring. Xyranik checks measurability first, and would rather tell you a goal cannot be tracked than show you a confident line with nothing behind it.
ExecutionOne plan, every channel, checked twice
Most of what goes wrong in marketing automation goes wrong between deciding and doing: the send that went twice, the budget change that was approved on Monday and applied against Thursday’s limits. Execution is built around those two failures.
MeasurementRevenue traced back, or plainly untraceable
Every analytics product will tell you what worked. The difference is what it does when it does not know. Xyranik’s answer is to say so — in a dash with a reason rather than a zero, and in a coverage figure before any share is quoted.
Layer two
Agent trust layer
Not cybersecurity bolted on. This is what lets an agent act at all: every action is decided before it happens, by deterministic code rather than by the model that asked for it.
Agent identityEach agent is somebody, not a setting
If an agent acts as the person who configured it, then every agent has that person’s access, "pause that one" means nothing, and the audit log records a human for something no human did. Separating the two is what makes the rest of the trust layer possible.
Permissions and policyDeny by default, in your own words
Permission systems fail in two ways: they default to open, and they can be evaded by leaving a detail out. Both are closed here, and the second one matters more than it sounds.
Risk and approvalsFour gates, one inbox
Four independent checks sounds like bureaucracy until you notice they fail differently: one is about volume, one about the kind of change, one about how much this workspace has earned, and one about the action itself. What would be exhausting is four separate queues, and there is only one.
Action gatewayEvery action decided before it happens
This is the load-bearing piece. If an agent could reach the outside world without passing this, everything else on this page would be decoration. So there is one path, our own agents use it, and the model asking is never the thing that decides.
Tenant isolationOne workspace can never read another
Most software keeps customers apart by filtering in the right places and trusting everyone to keep doing it. That holds until somebody writes a query in a hurry. Here the thing that would have to go wrong is narrower, and it is the same boundary whether the reader is a person, an API token or an agent.
Prompt-injection defenceWhat an agent reads can never widen what it may do
Agents read things strangers wrote: a customer’s email, a competitor’s page, a campaign name. Somewhere in that text, eventually, will be a sentence addressed to the machine. The defence that matters is not detecting it — detectors miss things — but making the successful case worthless.
Credential protectionSealed before they are stored, under a key that rotates
Connecting a store or an ad account means handing over a key that can spend money. What matters is not that it is "encrypted" but what happens when the key protecting it has to change — and whether a misconfiguration fails loudly or quietly.
Audit and decision ledgerAppend-only, sealed nightly
Two records, with different jobs. One says what happened. The other says what was expected to happen, written down before anybody knew, which is the only way to find out whether the system is actually any good.
Kill switchOne switch, and it fails closed
A stop button is only worth having if you know exactly what it stops and what happens when the system cannot tell whether it has been pressed. Both answers are here, and the second is the one most products get wrong.
Layer three
Infrastructure
The same layer Xyranik's own agents run on, opened up. An agent you built asks the same question — may this agent do this, here, now? — and is held to the same permissions, limits and record.
- Endpoints served
- 24
- Webhook events
- 18
- Requests an hour, per token
- 600
- Per agent credential
- 1,200
Agent APIYour agents, on our trust layer
The trust layer is not a Xyranik feature that happens to be exposed. It is infrastructure, and an agent you wrote elsewhere can hold a credential, ask the gateway for permission, and be refused by the same code that refuses ours.
Tool registryTools are the security boundary
An agent is dangerous because it can act, not because it can reason badly. A model choosing the wrong tool is recoverable; a tool that lets it spend money without a ceiling is not. So the registry — not the prompt — is where capability is defined.
WebhooksSigned, rotated, and never sent inward
A webhook sender is an SSRF primitive wearing a friendly name: you hand a service a URL and it fetches it. The guard against that is the load-bearing part of this feature, and it is checked twice on purpose.
Usage and meteringNothing metered is ever unlimited
Usage limits usually fail in one of two ways: they are checked and then acted on, so two simultaneous requests both pass; or they are exceeded quietly and appear on a bill. Both are closed here, and the first one is closed atomically rather than carefully.
Three answers, and only one is yes
Available now- allowed
- Go ahead. mayProceed is true.
- requires_approval
- A person in the workspace has to decide first. This is not a yes.
- denied
- No, with the reason and the check that refused it.
A leaked workspace token is the workspace. A leaked agent credential is one agent, and revoking it stops that one.
The developer area carries the request and response for each of these, with a copy button.
Make your first callEvery control, and what is not built
The security page lists each of these as something you can check in the product, and lists separately what is not in place — including that Xyranik holds no certification and has had no external audit or penetration test.