TradeVoice
A multi-tenant support workspace where conversations can search business records and prepare enquiries, with server-owned permissions and exact-action confirmation before a write.
What it is
Business conversations become useful when they can act on records, but a plausible sentence is not authorization. TradeVoice makes the proposed enquiry visible and requires confirmation of those exact details before it writes anything.
The dashboard gives a reviewer a complete local flow: sign in, inspect workspace data, simulate a call, ask for a distributor, create an enquiry, and inspect what happened afterward.
The loop it has to make believable
- 01
Search distributors, fill missing enquiry details over several turns, review the exact proposed action, and confirm before creating a record.
- 02
Simulate a call, follow its lifecycle in the dashboard, and inspect the worker-generated summary and audit trail.
How it’s built
FastAPI supplies authenticated context to a bounded tool registry. Confirmation records store a canonical payload hash and expiration; the service checks identity and consumes the confirmed action transactionally. The source includes a concurrency test for repeated consumption.
PostgreSQL owns business records and audit state. A Redis worker handles summaries with explicit retry and dead-letter behavior. Deterministic NLU makes the default demonstration runnable without provider credentials.
Architecture
- Workspace
- Authenticated principals supply user, workspace, and role context to an allowlisted tool gateway
- Conversation
- Intent scoring, entity grammars, and multi-turn slot filling resolve requests against workspace data
- Confirmation
- Payload hashes, expiry, and transactional consumption bind approval to a specific enquiry
- Background work
- Redis summary jobs include retries, dead-letter handling, worker heartbeat, and queue health
- Operations
- Alembic migrations, structured logs, request IDs, health probes, and container deployment configuration
What has to hold up
- Derive tenant identity on the server and require fresh confirmation tied to the same user, workspace, session, and payload.
- Handle retried and concurrent confirmation consumption without creating a second enquiry; exercise worker failures separately from the request path.
Integration boundary
The default path invokes no generative model. The OpenAI Realtime adapter is wired in but tested against a simulated upstream; live project-key behavior and voice latency are not established. The Twilio endpoint checks signatures, but live carrier audio has not been verified.
This case study demonstrates the control plane around conversational actions. It does not claim a deployed voice agent or measured production call quality.
Proof
VerifyRepository, checks, stack, status
- 01
Use the README's Docker Compose path and open the local demo workspace.
- 02
Create an enquiry through the support panel, checking the read-back and confirmation step.
- 03
Inspect enquiries.py and test_tools.py, then follow the repository's make verify instructions and PostgreSQL integration path.
- 04
Read the live-integration limitations before interpreting the mock flow as voice-provider evidence.
- Role
- Backend control plane, authorization, confirmation workflow, queue processing, and dashboard integration
- Scope
- Local multi-tenant support dashboard, conversational tools, and call lifecycle
- Proof
- README; backend/app/services/enquiries.py; backend/tests/test_tools.py, test_worker.py, and test_realtime.py; frontend browser tests
- Stack
- Python, FastAPI, PostgreSQL, Redis, React, TypeScript, Alembic, Docker
- Default engine
- Deterministic NLU
- Writes
- Exact-payload confirmation
- Isolation
- Workspace-scoped access
- Processing
- Redis summary worker