Every change gets an agent.
You define the goal and the guardrails.
A change is the fundamental unit of product work — introducing something new, or modifying something that exists. Both are a change. Traffical moves each one from idea to default through the same governed, measured lifecycle — and an agent can drive it, because the goal and the limits were set before it started.
Built on the parameters, layers, and policies in how it works. A change adds intent, approval, and retained learning on top — and it's a layer you can add when you want it, not a prerequisite.
Turn the values you keep redeploying into parameters
Install the SDK, then name the values you want to control. That's the integration.
Anywhere your product has a hardcoded number, string, or flag that a person might reasonably want to change — a discount, a headline, a ranking weight, a model temperature, a threshold — you replace it with a named parameter read through the SDK, with the current value as its default.
You do this once. From then on, that value is controllable from the dashboard, and every change to it can be staged, measured, and governed without touching the codebase again.
React
Next.js
Svelte
Node
Python
React Native TypeScript PHP Swift / iOS + OpenFeatureA given user buckets identically on every platform, so web, app, and backend agree on what that user sees.
// redeploy to change const discount = 10; applyDiscount(discount);
// controllable, default kept const { discount } = traffical.getParams({ context: { userId: user.id }, defaults: { discount: 10 }, }); applyDiscount(discount);
Your default is the floor
If nothing is running, if the config hasn't loaded, if Traffical is unreachable — the SDK returns the default you wrote in code. Nothing can break by being absent.
Change the value once — every surface follows
The payoff of a central parameter: web, app, backend, and email can't drift apart.
One value, four consumers
The shape of the problem a central parameter removes.
Most teams have the same discount logic in four places: the storefront, the mobile app, the pricing service, and the win-back email. Changing "10%" means four tickets, four deploys, and a window where they disagree.
One parameter, consumed everywhere, removes that class of problem. The value resolves from a single source, so a change lands everywhere at once — or nowhere. There is no partial state to reconcile.
- No drift — the same user sees a consistent value across every surface and session.
- No coordination — front-end and back-end teams don't need to ship together.
- One place to look — what is this value right now, and who last changed it?
Read natively on every platform
Each SDK resolves the same key in-process, with a compiled fallback.
The same parameter key, read natively on every platform that touches the experience. No shared client library to write, no config file to keep in sync, no per-surface reimplementation of who-gets-what.
const { discount } = useParams({ defaults: { discount: 10 }, });
params = traffical.get_params( context={"user_id": uid}, defaults={"discount": 10}, )
let discount = traffical.number( "pricing.discount_pct", default: 10 )
Bound to the surfaces that consume it
What the value does on each surface is what makes a change classifiable.
A surface is a place your product meets a user — checkout, a mobile screen, a ranking service, an email. Parameters are bound to the surfaces that consume them, and each binding records what the value actually does there.
That binding is not documentation. It's what lets Traffical compute how risky a change is before it runs: a value that merely renders is safer than one that drives a decision or writes to a system of record.
| Surface | Kind | Role |
|---|---|---|
| Checkout | frontend | render |
| Mobile app | frontend | render |
| Pricing service | backend | decision |
| Win-back email | render |
One page per parameter
The current value, who is overriding it, and in what order it resolves.
Every parameter has its own page: what type it is, what the default is, which surfaces consume it, and which policies are currently overriding it. It's the answer to "what is this value right now, and why?"
Values resolve in a fixed order, so the outcome is always explainable — a base default, an optional per-environment override, and the highest-priority policy override on top.
Agree what counts as better — once, for everyone
This is where the goal and the guardrails come from — not from whoever opened the change.
A certified metric is one approved definition, versioned and validated, that the whole organisation shares. One meaning of "margin", one meaning of "active user" — not seventy team-specific variants that quietly disagree. Your data team owns certification; a change can only reference definitions that already carry it.
A protocol bundles those metrics into a reusable measurement template the platform knows how to run: what the objective is, which secondary metrics to watch, which guardrails apply with what thresholds, and which diagnostics catch instrumentation drift. Protocols are how the design of a sound experiment stops being something anyone has to reinvent.
When a change is created it resolves its measurement plan from the protocols that match its surfaces, and snapshots that plan. Change the protocol next month and the running change keeps the version it started on — so an old decision stays reconstructable.
- Versioned — a certified definition has a history, and so does every threshold on it.
- Reusable — certify once, and every change on that surface inherits it.
- Snapshotted — the plan a change ran against is frozen at start.
No certified protocol, no traffic
If nothing certified covers the change, it can be drafted but not started — until a person approves its metrics and guardrails explicitly. This is the line an agent cannot cross, because inventing the yardstick is not one of its permissions.
Every change on the Checkout surface resolves this protocol — so the bar is the same one, every time, whoever opened it.
A change is a set of parameter values plus a plan to prove them
New feature or a tweak to an existing one — both are a change. Same lifecycle.
You state the intent — what this is for — and pick the parameters involved. Then you define the variants: each variant is simply a named set of values for those parameters. A control variant is the current default, so you're always comparing against the real status quo.
Traffical computes a risk class from the surfaces those parameters touch and recommends a lifecycle template — the sequence of phases the change will move through. Rollout is one of those phases, not the whole story.
| Variant | discount_pct | free_shipping |
|---|---|---|
| control | 10 | false |
| generous | 15 | false |
| bundled | 10 | true |
One change can move several parameters together — that's how you test a coherent experience rather than an isolated toggle.
Strategy
Based on the surfaces your parameters touch, we computed a risk class and recommend a lifecycle. Adjust either before continuing.
Exposure grows only as the evidence allows
Rollout is a phase inside the change — not a separate tool, not a separate process.
Each phase answers one question before the next begins. The canary asks is this safe? on a 1% slice. The experiment asks is it better? against a real control. The rollout asks does it hold? as exposure ramps in health-gated steps. Complete promotes the winning values into the parameter defaults.
Users aren't re-randomized between phases — a user in the treatment arm during the canary stays there through the experiment, so no cohort is contaminated.
Guardrails are attached per phase with thresholds agreed up front. A blocking breach pauses the phase automatically and users fall straight through to the defaults. Nobody has to be watching a dashboard at 3am.
On a blocking breach
The phase pauses, exposure drops to zero, and a decision record is written with the evidence that triggered it. Default response is pause; revert is one click.
Across every step
You decide how much of this runs itself
Autonomy is a setting, not a property of the product. It starts at zero.
Nothing in the model requires you to hand anything over. On day one every action is a proposal that waits for a person, and the platform's value is that the proposal arrives complete — intent, measurement plan, guardrails, and current evidence already assembled.
From there you move the dial, per risk class, at whatever pace earns your trust. Teams typically let low-risk render-only changes start themselves within weeks, and keep a person on anything that touches pricing or a system of record indefinitely.
The dial only ever governs who may act without asking. It never changes what the rules are, and it never applies to promoting a change into your product defaults.
| Stage | Who may act | Who must approve | At setting 3 |
|---|---|---|---|
| Parameterize | engineering | human | unchanged |
| Certify metrics & protocols | data / analytics | human, always | unchanged |
| Set guardrail thresholds | product + data | human, always | unchanged |
| Define a change | agent or human | human | agent may start it |
| Start traffic | agent or human | human below risk cap | agent, within cap |
| Advance a phase | agent or human | evidence gate | agent, if clean |
| Pause or revert | automatic | none — it just stops | unchanged |
| Promote to default | — | human, always | still human |
Read the last column first. Even at maximum autonomy, four things never move: what counts as better, what counts as unacceptable, which protocols are valid, and what becomes your product's default.
Agents, people and automatic responses write to the same log with the same fields — so "who did what, when, and against which thresholds" is one question with one answer, not two systems to reconcile.
Results you'd put in front of your data team
A verdict for the review, with the per-variant detail your data team needs.
What you find out stays found out
A closed change is a record, not a closed ticket.
When a change completes, the outcome doesn't evaporate into a closed ticket. The question, the variants, the evidence, the verdict and the reasoning are kept together as a durable record — searchable by parameter, surface, or metric.
So the next time someone proposes a more aggressive discount, the answer to "did we try this?" takes ten seconds instead of a week of archaeology. New team members inherit the institutional memory instead of rediscovering it, and the next iteration starts from what you already know rather than from zero.
The audit record is the proof underneath it: every start, advance, promotion, pause, and revert, with who acted, what the evidence said, and which thresholds were in force at the time. Versioned and snapshotted, so a decision three weeks old can still be reconstructed exactly.
Prior results are context for the next proposal — human or agent — so iteration compounds instead of looping.
The reasoning stays attached to the change, not to the person who happened to run it.
The same rules hold when an agent is driving
Stated intent, an approved plan, guardrails on every phase, a record at the end.
Your team already ships with AI assistance. Traffical is built so that work arrives through the same front door as everything else — stated intent, an approved measurement plan, guardrails on every phase, and a decision record at the end.
Structured, not freeform
An agent fills in a change the same way a person does. There's no side channel into production.
Guardrails aren't optional
Thresholds are set by your team, in advance. An agent can't widen them or measure against something else.
Defaults still need a person
Making a value the permanent product default is always a human approval. Always.
Reads what came before
Accumulated results are context, so an agent proposes the next experiment rather than repeating an old one.
Where this goes
Governance is what makes autonomy affordable
Each rung needs the one below it to already be true.
The reason to build the change model now isn't paperwork. It's that every step toward a product that improves itself needs the same four things to exist as data rather than as a slide: what we're trying to achieve, how we'd know if it worked, what must not break, and what we already learned. Protocols, objectives, guardrails, and the decision log are exactly those four — which is why the governance layer is the thing that unlocks autonomy rather than the thing that slows it down.
Agents draft the code and scaffold the change. A person drives every transition and writes the readout. This is where most teams are today.
Agents and monitors propose transitions, with the evidence they decided on bound to the proposal. A person reviews and approves. Safety actions already run unattended.
Low-risk changes advance themselves inside certified protocols, and guardrail breaches self-contain. People hold promotion, exceptions, and anything above the risk line they set.
The product continuously proposes, validates, and retires its own changes against objectives you set — compounding on its own decision log. People own the objectives, the guardrails, and what "better" means.
You pick the rung per risk class, not per company. Copy on a marketing page can sit at rung four while pricing stays at rung two — the same organization, two different autonomy settings, both fully audited.
And because the ladder is configuration rather than architecture, moving up isn't a migration. It's widening what the same gates already permit. Nothing about rung four changes the fact that a human certified the metric and set the threshold.
Build the guardrails before you need the speed
Parameterize a single value this week. The governance you add around it is what lets you hand more of it over later.