Adding commercial guardrails to Lindy agents

You add commercial guardrails to Lindy agents by inserting an HTTP request step between the step that drafts a message and the step that sends it: the request posts the draft to EvalLayer's /authorize endpoint, a condition step branches on the returned decision, and the send step uses either the original draft or the approved rewrite, with only flagged cases routed into Lindy's confirmation flow. It is one extra step in the flow editor, and it converts review-everything into review-what-matters.

Why Lindy agents need a policy layer

Lindy is built for exactly the work where commercial slips happen: email triage and replies, outbound sequences, meeting scheduling, CRM updates, customer follow-ups, wired through thousands of app integrations and triggered automatically. A Lindy that answers inbound leads is quoting, conceding, and promising in your name all day. The volume is the point of the product, and volume is what turns an occasional over-generous sentence into a standing liability.

Lindy's native answer is human-in-the-loop: the Ask for Confirmation toggle on side-effect actions holds the send until you approve it in the task view, and it is rightly one of the platform's most-used features for outreach. Its limit is arithmetic. Confirmation is all-or-nothing per action, so either every email waits on a click, which caps the agent at your reading speed and trains you to rubber-stamp, or you switch it off and trust the prompt. There is no notion of policy in the middle: nothing that knows 8 percent off is fine, 20 percent is not, and a delivery promise is never fine. That graded judgment is what the authorization step adds.

The interception point: an HTTP step before the send

Lindy flows compose triggers, AI steps, and actions, and the HTTP request step can call any API mid-flow with outputs available to later steps. Place one immediately after the drafting step. Configure it as a POST to https://api.evallayer.ai/authorize with an Authorization header of Bearer sk_your_key and a body that maps in the draft from the previous step's output:

{
  "action_type": "send_reply",
  "content": "(map the drafted email body from the previous step here)",
  "context": {
    "platform": "lindy",
    "recipient": "(map the recipient here)",
    "flow": "inbound-lead-replies"
  },
  "policy": {
    "max_discount_pct": 8,
    "commitment_authority_usd": 500,
    "forbidden_commitments": ["delivery_date", "refund_promise"],
    "approved_claims": ["cancel_anytime"],
    "required_disclaimers": [],
    "blocked_topics": ["legal_advice"]
  }
}

The response gives later steps four fields to work with: decision, approved_rewrite, authorization_id, and violations. Add a condition step on decision with four branches.

Wiring the four branches

• allow: proceed to the send step with the original draft. No confirmation needed; policy already passed it.
• rewrite: proceed to the send step, but map its body from approved_rewrite instead of the draft. The prospect receives the compliant version and the flow never pauses.
• require_approval: route into a send step with Ask for Confirmation enabled, and include the violation detail and authorization_id in the task so the human sees why it was flagged. This is where Lindy's native review shines, now aimed only at the drafts that earned it.
• block: skip sending entirely. Log the authorization_id to a sheet or your CRM, and optionally notify a channel so a human can follow up manually.

Latency in an async flow

Most Lindy sends are asynchronous, replying to an email or advancing a sequence, so latency barely registers: deterministic policy checks return in milliseconds and semantic checks in one to two seconds, invisible next to a send that was going to happen whenever the flow ran. If you attach a Lindy to a live chat surface, keep the check at the reply-send moment rather than on every internal step, the same commitment-moment rule that applies to voice agents.

What to log

Add a final step on every branch that writes authorization_id, decision, and risk_score next to the message record, in the same sheet, CRM, or database the flow already updates. Six months from now, "what did the agent offer this customer and who approved it" is a filter on that log, not a search through sent mail.

Try it in ten minutes

Duplicate your flow, point the HTTP step at /demo/authorize (three free checks per day, no key), and run a test trigger; or preview the decision card at the interactive demo first. For what each decision means, read the authorization guide; for choosing the numbers in the policy object, read policy design.