Polaris × TrueFoundry present
Built for the harness. Proven in execution.
roaming resolverTelecom customer support · Agentic investigation
One disputed roaming charge. Proven, not guessed.
An agent that investigates a billing dispute, proves the answer with executed code, and stops before external impact. Watch the full run:
Minutes
to resolve a roaming dispute that today takes days of manual back-and-forth.
Zero
unreviewed customer-facing actions. Every external step waits for a person.
100%
auditable. Every run ends in a decision record with a verifiable evidence hash.
The workflow
What it does. How it works. Why it wins.
What it does
Reads the dispute
A subscriber disputes a roaming charge. The agent picks up the ticket from Linear.
Pulls the evidence
Scoped MongoDB Atlas records only — customer, country, partner, time window.
Settles the math
Billed vs. expected, computed by executed code — not by a language model's guess.
How it works
Freezes one command
The exact calculation is locked before it runs. No improvisation.
Executes in isolation
TrueForge runs it once in an E2B sandbox — 20-second limit, fully traced.
Proves the result
A SHA-256 evidence hash binds ticket, records, command, and result.
Why it wins
Reaches real systems
Live Linear + Atlas via scoped MCP tools. Not a mock, not a demo script.
Runs real code
Native E2B execution through the TrueForge harness — the hackathon's core ask.
Knows when to stop
A human approves the correction. The customer reply is drafted, never sent.
Under the hood
Architecture built for trust
The operator console hands a scoped ticket to the TrueForge harness. TrueForge enforces policy, executes one calculation in E2B, records evidence, and pauses before the approved correction.
Architectural decisions
The questions a judge should ask
Why execute in an isolated E2B sandbox instead of in-process?
Untrusted ticket text is never treated as instructions. One frozen command runs once, with a 20-second limit, far away from production data.
Why require human approval before posting to Linear?
The agent proves; a person decides. External impact stays human-controlled — the exact payload and target are reviewed first.
Why only six narrow, scoped tools?
Least privilege. read_evidence sees only the customer, country, partner, and time window — nothing else in the database.
Why a SHA-256 evidence hash?
It binds ticket, records, command, and result into one auditable decision record — rechecked before any action.
Why idempotent posting?
Retries and double-clicks can never create a duplicate correction comment.
Why hold the customer reply?
approve_reply_draft approves a local draft only. No customer message is ever sent automatically.
Why Azure OpenAI with an OpenAI fallback?
An enterprise-grade model route with an availability backup — the run never dies because one provider is down.
Why a MECE workflow?
Discovery, Execution, and Control don't overlap and together cover the whole job — every step is auditable, nothing is missed.