Add AssemblyAI universal-3-5-pro with conversation-context carryover

[dlange-aai]

What & why

Upgrades pipecat-ai to >=1.4.0 and adds first-class support for AssemblyAI's universal-3-5-pro streaming STT model (the Universal-3 Pro family) plus pipecat 1.4.0's new conversation-context carryover, so the agent's most recent reply seeds the STT before the user's next turn — improving transcription of short answers, spelled-out entities (codes/emails/IDs), and disambiguation.

Changes

• pyproject.toml / uv.lock: pipecat-ai>=1.0.0 → >=1.4.0 (one new transitive dep, pyyaml-include; no other churn).
• services.py:
  • New update_stt_agent_context(stt, text) helper — forwards the agent's reply to AssemblyAISTTService.update_agent_context() when the STT exposes it (AssemblyAI U3 Pro), no-op otherwise.
  • Plumb vad_force_turn_endpoint through EVA_MODEL__STT_PARAMS — it's a constructor arg (not a Settings field), so the existing dataclasses.fields(...) forwarding didn't carry it. Default True (Pipecat-mode).
  • Model selection and the new carryover Settings fields (agent_context, previous_context_n_turns) already flow through the existing dataclass forwarding — no extra code.
• pipecat_server.py: call the helper from the cascade on_assistant_response hook so each agent reply seeds STT context.
• .env.example: documented AssemblyAI universal-3-5-pro example with carryover + tuning fields.
• tests: AssemblyAI tests use universal-3-5-pro; cover carryover-Settings forwarding, the update_stt_agent_context helper (forward / no-op-absent / empty / None), and vad_force_turn_endpoint default + override.

Why explicit carryover (not pipecat's automatic path)

In a standard pipecat bot, carryover fires automatically: the assistant context aggregator emits LLMContextAssistantTurnFrame, the upstream STT picks it up via _process_assistant_turn(), and the AssemblyAI override calls update_agent_context(). EVA's cascade pipeline drives the agent turn through a custom BenchmarkAgentProcessor that pushes TTSSpeakFrame directly and does not emit the standard LLM response frames, so that aggregation is empty and the frame is never produced. We therefore trigger the update explicitly from the existing assistant-response hook. The call is idempotent with the auto-path (update_agent_context replaces rather than accumulates), and universal-3-5-pro is recognized by pipecat's U3_PRO_MODEL_PREFIXES, so it gets the full feature set.

Verification

• Full unit suite passes on pipecat 1.4.0 (1765 passed, 52 skipped, 3 xfailed).
• End-to-end cascade runs with universal-3-5-pro + Cartesia sonic-3: conversations complete, and carryover is confirmed firing on the live run (AssemblyAI's _clip_agent_context logs the agent reply being sent each turn).

Notes

• Scope is the cascade pipeline. The audio-LLM path transcribes via a separate branch and is intentionally not wired here.
• The carryover update is awaited before the agent's TTS frame is pushed (by design — the context must be set before the user's next turn).

[JosephMarinier]

Very nice! I ran a few test evals with context carryover and it worked well. Thank you very much!

[JosephMarinier]

With "vad_force_turn_endpoint": true (the default), if we set max_turn_silence like this, we get this warning:

Your max_turn_silence value (100ms) will be OVERRIDDEN in Pipecat mode (vad_force_turn_endpoint=True). It will be set to 100ms (matching min_turn_silence) and SENT to AssemblyAI to avoid double turn detection. To use your max_turn_silence as-is, switch to AssemblyAI turn detection mode (vad_force_turn_endpoint=False).

So, should we clean that up?

Suggested change

	#i EVA_MODEL__STT_PARAMS='{"api_key": "your_assemblyai_api_key", "model": "universal-3-5-pro", "vad_threshold": 0.1, "min_turn_silence": 100, "max_turn_silence": 100, "vad_force_turn_endpoint": true}'
	#i EVA_MODEL__STT_PARAMS='{"api_key": "your_assemblyai_api_key", "model": "universal-3-5-pro", "vad_threshold": 0.1, "min_turn_silence": 100, "vad_force_turn_endpoint": true}'

[JosephMarinier]

See my other comment first. Then, to be consistent, should we clean that up too?

Suggested change

"max_turn_silence": 100,

We can leave the assert svc._settings.max_turn_silence == 100; it works. That said, I'm not sure if that's something EVA needs to test (as opposed to a unit test in Pipecat). I'll leave it up to you.