I run a no-code agency. Do I need a developer for this?

Not necessarily. The authorization call is one HTTP action with a JSON body, configured the same way you configure any CRM or calendar action in Synthflow, or routed through the Make and Zapier connections Synthflow already supports. If you can map response fields to variables, you can wire the four decisions.

Can each client have a different policy?

Yes, and that is the point for agencies. The policy object travels with each request, so the same agent template can carry a 10 percent discount cap for one client and zero discount authority for another, without cloning or re-prompting the agent. Policy changes are config changes, not redeployments.

How do I try it without committing?

POST a sample offer to /demo/authorize, which gives you three free checks per day with no API key, or watch the interactive demo at /authorize-demo catch planted violations. Production requests use a Bearer sk_ key or $0.01 per request over x402.

Adding commercial guardrails to Synthflow agents

Published 2026-07-27 · EvalLayer

You add commercial guardrails to Synthflow agents by inserting an API action at each commitment point in the flow: the action posts the drafted offer to EvalLayer's /authorize endpoint, the response comes back as flow variables, and the flow branches on the decision so the agent only speaks or books what passed policy. No code in the agent itself; the guardrail is one more action in the Visual Flow Designer.

Why no-code voice agents need an enforcement layer

Synthflow's pitch is speed: agencies and SMB teams ship phone agents for booking, lead qualification, and front-desk work without writing code, using flow templates, subflows, and a marketplace of prebuilt patterns. That speed has a flip side. When the builder is not a developer, the only place policy usually lives is the prompt, written in plain language, and a prompt is a suggestion the model follows most of the time. A caller who pushes back, bargains, or asks the right leading question can walk a prompt-governed agent past its limits, on a recorded line, in the client's name.

The agency angle sharpens this. One Synthflow workspace often runs agents for many clients, each with different pricing, refund rules, and claims they are allowed to make. Duplicating agents and hand-editing prompts per client does not scale and leaves no evidence of what was enforced. An external policy check does both: the rules live in a per-client policy object, and every decision returns an authorization_id you can show the client.

The interception point: an action before the say or send step

Synthflow's extension surface is its actions and integrations layer: flows can call external APIs mid-conversation, capture the response into variables, and branch on them, the same mechanism used for calendar lookups and CRM writes. The guardrail pattern uses exactly that. At the point in the flow where the agent has assembled an offer (a price, a booking with terms, a refund), add an API action that calls /authorize, then branch on the returned decision before the node that speaks or sends.

Configure the action as a POST with this body, mapping your flow variables into content and context:

POST https://api.evallayer.ai/authorize
Authorization: Bearer sk_your_key
Content-Type: application/json

{
  "action_type": "send_quote",
  "content": "Here is the offer text the agent intends to speak,
              assembled from your flow variables.",
  "context": {
    "channel": "voice",
    "platform": "synthflow",
    "client": "acme-dental"
  },
  "policy": {
    "max_discount_pct": 10,
    "commitment_authority_usd": 300,
    "forbidden_commitments": ["refund_promise", "delivery_date"],
    "approved_claims": ["same_week_appointments"],
    "required_disclaimers": [],
    "blocked_topics": ["competitor_pricing"]
  }
}

Map four response fields to variables: decision, approved_rewrite, authorization_id, and risk_score. If your Synthflow plan makes complex branching awkward, the same call slots into a Make or Zapier scenario between Synthflow and the outbound step; the architecture is identical, only the host of the HTTP step changes.

Branching on the four decisions

allow: continue to the speak step with the original offer text.
rewrite: speak the approved_rewrite variable instead. The caller hears the compliant version, capped and corrected, with no refusal moment.
require_approval: branch to a callback path. The agent says the offer needs a quick sign-off and promises a follow-up; the draft and authorization_id go to a human queue via your CRM or a notification action.
block: branch to a redirect path, never speaking the draft, and log the authorization_id. The violations array tells you which rule fired.

Latency in a no-code flow

Only check at commitment moments; greetings and qualification questions should never wait on a policy call. Deterministic policies (discount caps, authority limits, required text) return in milliseconds. Semantic checks take one to two seconds, which reads as a natural pause if the preceding node has the agent say something like "one moment while I confirm that." This is the same latency you already accept for a calendar availability lookup.

What to log

Keep the authorization_id with the call record your flow already writes to the CRM. For agencies, this becomes a client deliverable: a per-call ledger showing every offer the agent attempted, what policy said, and what was actually spoken. It is a materially better answer to "how do we know the AI will not overpromise" than a screenshot of a prompt.

Start with the demo

Run one offer through /demo/authorize (three free checks per day, no key) or the interactive demo before touching a live flow. Then read the authorization guide for decision semantics and policy design for setting per-client caps that match real authority.