Question: try scripted regression tests against a realtime voice agent server?

[monkeyin92]

Hi Streamcore team! Your project is very close to the kind of realtime voice-agent stack I’m trying to validate against, especially because it includes WebRTC, STT/LLM/TTS pipelines, SIP, and local/self-hosted paths.

I’m building a small open-source Voice Agent TestOps tool for pre-launch regression testing: https://github.com/monkeyin92/voice-agent-testops

It sends scripted customer turns to an HTTP/OpenClaw-compatible endpoint and checks practical launch risks:

• unsafe pricing / over-promising
• missed lead fields like phone or preferred time
• wrong human-handoff intent
• latency over threshold
• JSON + HTML/PDF reports for CI or sales review

Example command:

npm run voice-test -- --suite examples/voice-testops/openclaw-suite.json --agent http --endpoint <your-test-endpoint>

Would you be open to running one suite against a Streamcore demo agent, or pointing me to a better place to ask? I’m happy to adapt the suite to a Streamcore example domain and share the report back.

[jason-shen]

Hi Streamcore team! Your project is very close to the kind of realtime voice-agent stack I’m trying to validate against, especially because it includes WebRTC, STT/LLM/TTS pipelines, SIP, and local/self-hosted paths.

I’m building a small open-source Voice Agent TestOps tool for pre-launch regression testing: https://github.com/monkeyin92/voice-agent-testops

It sends scripted customer turns to an HTTP/OpenClaw-compatible endpoint and checks practical launch risks:

• unsafe pricing / over-promising
• missed lead fields like phone or preferred time
• wrong human-handoff intent
• latency over threshold
• JSON + HTML/PDF reports for CI or sales review

Example command:

npm run voice-test -- --suite examples/voice-testops/openclaw-suite.json --agent http --endpoint
Would you be open to running one suite against a Streamcore demo agent, or pointing me to a better place to ask? I’m happy to adapt the suite to a Streamcore example domain and share the report back.

yeah sure, there is a demo runing on streamcore.ai you can test on, that, but that only has very basic streamcore knowledge, or let me know what you need to test it, cheers

[monkeyin92]

Thanks, that works.

For a useful first pass, I need one scriptable test path rather than only a browser/manual demo. The easiest option is:

POST /test-turn
input:  { "text": "customer/user turn" }
output: { "spoken": "agent reply", "summary"?: { ...optional fields... } }

If Streamcore already exposes a WebSocket or HTTP route for the demo agent, I can adapt to that shape too. A sanitized sample transcript also works if an endpoint is not convenient.

Since the public demo only has basic Streamcore knowledge, I would start with a small suite around: asking what Streamcore does, unsupported promise/overclaim checks, handoff/contact intent, and latency/contract behavior.

No production credentials or private customer data needed.

[monkeyin92]

Quick follow-up. I can start with the public demo if there is a scriptable route behind streamcore.ai.

Minimum shape is just a way to send one user turn and receive the assistant reply, for example HTTP { "text": "..." } -> { "spoken": "..." }, or a WebSocket equivalent. If that is not exposed, one sanitized transcript is enough.

I put the public-safe proof examples here so the ask is more concrete:
https://github.com/monkeyin92/voice-agent-testops/blob/main/docs/growth/public-proof-gallery.md

I would only share aggregate findings back on the issue unless you explicitly approve more detail.

[jason-shen]

unfortunally there isn't a scriptable route, feel free to do a pr though, i am not sure what you need for the endpoint

[jason-shen]

i think a better idea is pull the repo and do test locally maybe? i don't think its a good idea to do test on a live agent, just my throughs

[monkeyin92]

That makes sense. I agree that testing against the live public agent is probably the wrong default, especially if it is shared/demo infrastructure.

I will pull the repo and try the local path first. From the README it looks like the clean baseline is:

• run the server locally with go run .
• use the existing /whip flow or SDK/example client for normal realtime testing
• only add a small dev/test-only text-turn adapter if needed for regression automation

What I likely need for the PR is not a production endpoint, but a local harness shape that can drive one deterministic user turn and collect the assistant text/events, something like:

POST /test-turn   # disabled by default / dev-only
{ "text": "what does StreamCoreAI do?" }
-> { "spoken": "...", "events": [...], "latencyMs": ... }

If the existing WebRTC DataChannel already exposes enough transcript/response events locally, I may not need a new HTTP route at all; I can write the adapter around that instead. I will start by cloning/running locally and then open a small PR or come back here with the exact minimal hook if the current interfaces are not enough.

No live-agent testing, no production credentials, and no private data involved.

[monkeyin92]

I went ahead with the local/dev-only route and opened a small draft PR: #5

The PR keeps the realtime /whip path unchanged and adds an opt-in test.turn_endpoint = true harness for local regression testing only:

POST /test-turn
{ "text": "what does StreamCoreAI do?" }
-> { "spoken": "...", "events": [...], "latencyMs": ... }

It is disabled by default and documented as not for public deployments. I also made it accept the same customerText shape my Voice TestOps HTTP adapter already sends, so if you are okay with the hook, I can use it locally without touching the live demo agent.

[jason-shen]

I went ahead with the local/dev-only route and opened a small draft PR: #5

The PR keeps the realtime /whip path unchanged and adds an opt-in test.turn_endpoint = true harness for local regression testing only:

POST /test-turn
{ "text": "what does StreamCoreAI do?" }
-> { "spoken": "...", "events": [...], "latencyMs": ... }

It is disabled by default and documented as not for public deployments. I also made it accept the same customerText shape my Voice TestOps HTTP adapter already sends, so if you are okay with the hook, I can use it locally without touching the live demo agent.

cool i will review it little later, let you know when its merge! cheers for the pr