Feature Flags for AI Agent Tools: Gate What Your Agent Is Allowed to Do

Your agent's tool list is its blast radius. Whatever the model can call, it will eventually call.

Most teams gate the model and the prompt carefully, then hand the agent issue_refund, send_email and delete_recordin one deploy. The prompt says "only refund when the customer asks". The prompt is a suggestion. The tool call is a side effect.

When a tool misbehaves you have two bad options: redeploy with the tool removed, or take the whole agent offline. Both are slow and both are all-or-nothing. A tool that is wrong for one tenant is usually fine for the rest.

A tool is a feature. Release it like one.

The fix is the pattern you already use for UI: register every tool in code, but decide at request time which ones the model is offered. One flag per side-effecting tool, evaluated for the tenant the agent is acting on. The model never sees a tool that is off, so it can't call it.

Filter the tool list before it reaches the model. This is the Featureflow Node SDK; the same shape works with any SDK:

import Featureflow from 'featureflow-node-sdk';

const featureflow = new Featureflow.Client(); // FEATUREFLOW_SERVER_KEY

// Every tool declares the flag that gates it. Read-only tools have none.
const tools = [
  { name: 'lookup_order',  flag: null,                 fn: lookupOrder  },
  { name: 'issue_refund',  flag: 'agent-tool-refund',  fn: issueRefund  },
  { name: 'send_email',    flag: 'agent-tool-email',   fn: sendEmail    },
];

function toolsFor(tenant: Tenant) {
  const user = new Featureflow.UserBuilder(tenant.id)
    .withAttribute('plan', tenant.plan)
    .withAttribute('region', tenant.region)
    .build();

  return tools.filter(
    (t) => !t.flag || featureflow.evaluate(t.flag, user).isOn()
  );
}

// Offer only the permitted tools — the model can't call what it can't see.
const response = await llm.chat({ messages, tools: toolsFor(tenant) });

Keyed on the tenant, bucketing is stable: a 10% rollout of agent-tool-refund gives the same 10% of tenants the tool on every request, so you can watch refund volume for that cohort before expanding. Targeting rules cover the rest — internal tenants first, then a plan tier, then everyone.

Limits belong in the variant, not the prompt

On/off is the first step. The second is putting the guardrails in the flag's JSON payload so you can tighten them without a deploy:

// Variant "limited": { "maxAmount": 50,  "requireApproval": true  }
// Variant "full":    { "maxAmount": 500, "requireApproval": false }
const policy = featureflow.evaluate('agent-tool-refund', user).jsonValue();

async function issueRefund({ orderId, amount }) {
  if (amount > policy.maxAmount) return { error: 'exceeds refund limit' };
  if (policy.requireApproval) return queueForHuman({ orderId, amount });
  return refunds.create({ orderId, amount });
}

The enforcement lives in the tool, not in the model's good intentions. Move a tenant from limited to full when the approval queue shows the agent getting it right.

The kill switch you actually want

With one flag per tool, an incident becomes a precise action: turn off agent-tool-email, for the affected region only, and the agent keeps answering questions with the rest of its tools. Every flip is recorded with who changed it and when, which is the record you need when someone asks why the agent stopped sending emails at 14:07.

👉 Featureflow gives you targeting, percentage rollouts and JSON variants on every flag, with an audit trail on every change. See featureflow.com or the docs.

#FeatureFlags#AIAgents#LLM#AIDevelopment#ContinuousDelivery