Who we are, up front
We're Tulip (tulip-agents on PyPI) — an open-source agentic AI SDK, Apache-2.0. Pre-GA (currently v2.4.0, actively developed, not a mature/enterprise-proven product) — flagging that plainly. Opening this as an issue first per your CONTRIBUTING.md ("Major Changes should be discussed first in an issue"), not jumping to a PR.
What we noticed
twilio-agent-connect-python gives an agent real, autonomous reach into Twilio's voice and messaging channels — outbound calls (Calls API passthrough, AMD), SMS/messaging sends, handoffs. As far as we can tell from the public repo, there's currently no approval, guardrail, or audit layer between "the agent decided to do this" and "the call/message actually goes out." That's a different risk shape than most agent-tool examples: a wrong tool call here doesn't just corrupt some local state, it places a real call or sends a real message to a real phone number — with real TCPA/consent exposure, real cost, real reputational risk if it dials or texts the wrong person.
We searched the codebase for any existing guardrail/approval/audit concept and didn't find one (could easily be wrong — genuinely asking, not asserting).
What tulip-agents could add
tulip.control.admit() — every proposed action is classified and weighed against a policy before it runs:
benign action (e.g. read-only lookup) -> executes normally
outbound call / SMS to a new/unverified # -> held for a human, never executes
Every decision — allowed or not — lands on a tamper-evident, hash-chained AuditTrail, independent of Twilio's own call/message logs: who initiated it, under what policy, at what time, with what outcome.
Concretely, this would look like wrapping the point where a tool call becomes a real outbound Calls/messaging API invocation (tools/, or a channel's send path) in an admission check — same shape as the on_error callback you added recently (#88), but pre-execution rather than post-hoc.
What this is not
Not a claim that every outbound action needs a human in the loop — most don't, and an admission gate that fires on everything is useless. It's a policy layer: cheap/low-risk actions auto-allow, actions matching risk criteria you define (new number, no prior consent record, high call volume in a short window, whatever your own policy wants) escalate or deny. tulip-agents would be a real dependency of an example only, not a core SDK dependency — same pattern we've used integrating with other projects.
Happy to build a real PoC
Not asking you to take this on faith — happy to build a working example against a real hook point in this SDK (not a toy), verify it end-to-end against a real (test) Twilio account, and show actual before/after behavior: a benign action executing normally, a flagged one genuinely held, with the audit trail to back it up. That's the standard we've held ourselves to on every integration we've built so far.
The ask
Whether this is a real gap from where you sit, and whether it's something worth a PoC at all — happy to narrow scope, adjust the hook point, or hear that it's not a fit. Genuinely asking, not assuming.
Who we are, up front
We're Tulip (
tulip-agentson PyPI) — an open-source agentic AI SDK, Apache-2.0. Pre-GA (currently v2.4.0, actively developed, not a mature/enterprise-proven product) — flagging that plainly. Opening this as an issue first per yourCONTRIBUTING.md("Major Changes should be discussed first in an issue"), not jumping to a PR.What we noticed
twilio-agent-connect-pythongives an agent real, autonomous reach into Twilio's voice and messaging channels — outbound calls (Calls API passthrough, AMD), SMS/messaging sends, handoffs. As far as we can tell from the public repo, there's currently no approval, guardrail, or audit layer between "the agent decided to do this" and "the call/message actually goes out." That's a different risk shape than most agent-tool examples: a wrong tool call here doesn't just corrupt some local state, it places a real call or sends a real message to a real phone number — with real TCPA/consent exposure, real cost, real reputational risk if it dials or texts the wrong person.We searched the codebase for any existing guardrail/approval/audit concept and didn't find one (could easily be wrong — genuinely asking, not asserting).
What tulip-agents could add
tulip.control.admit()— every proposed action is classified and weighed against a policy before it runs:Every decision — allowed or not — lands on a tamper-evident, hash-chained
AuditTrail, independent of Twilio's own call/message logs: who initiated it, under what policy, at what time, with what outcome.Concretely, this would look like wrapping the point where a tool call becomes a real outbound
Calls/messaging API invocation (tools/, or a channel's send path) in an admission check — same shape as theon_errorcallback you added recently (#88), but pre-execution rather than post-hoc.What this is not
Not a claim that every outbound action needs a human in the loop — most don't, and an admission gate that fires on everything is useless. It's a policy layer: cheap/low-risk actions auto-allow, actions matching risk criteria you define (new number, no prior consent record, high call volume in a short window, whatever your own policy wants) escalate or deny.
tulip-agentswould be a real dependency of an example only, not a core SDK dependency — same pattern we've used integrating with other projects.Happy to build a real PoC
Not asking you to take this on faith — happy to build a working example against a real hook point in this SDK (not a toy), verify it end-to-end against a real (test) Twilio account, and show actual before/after behavior: a benign action executing normally, a flagged one genuinely held, with the audit trail to back it up. That's the standard we've held ourselves to on every integration we've built so far.
The ask
Whether this is a real gap from where you sit, and whether it's something worth a PoC at all — happy to narrow scope, adjust the hook point, or hear that it's not a fit. Genuinely asking, not assuming.