LDsuperduperkoolLoom Link: truedrug truedrug is a prototype that estimates the probability an FDA drug application will be approved during its first review cycle. It focuses on once-weekly injectable GLP-1–based treatments for type 2 diabetes. What it does The system turns pre-action public FDA evidence into a blinded dossier, then runs independent reviews across three disciplines: - CMC — chemistry, manufacturing, and controls - Pharm/tox — pharmacology and toxicology - Clinical — clinical evidence and safety Those reviewers produce structured, evidence-grounded findings. Deterministic code—not an LLM—then combines findings with a cited base rate and versioned likelihood-ratio table to calculate an approval probability and assemble a draft Complete Response Letter (CRL). Why blinding matters Models may already know drug outcomes. To avoid outcome leakage, the system removes drug, sponsor, trial-program, site, registry, application, and identifying URL information before review. The harness never receives outcome labels or blinding maps. Project structure - docs/domain/ — shared contracts, checklists, regulatory context, and leakage rules - specs/001-data-collection/ — evidence and dossier preparation - specs/002-frontend/ — planned demo interface - specs/003-harness/ — reviewer orchestration and prediction pipeline - specs/004-evals/ — offline evaluation and leak-probe scaffold - harness/ — harness implementation work - evals/ — synthetic evaluation fixtures and checks - splash/ — visual design material Local setup Open TrueForge at TrueForge is the local agent configuration environment. The polished truedrug frontend is planned separately and is not currently served by this repository. Principles - Reviewers use only dossier evidence and their assigned checklist. - Each checklist item receives exactly one finding. - Findings must be grounded in dossier evidence. - Model output is validated and may be repaired once; invalid output fails rather than being fabricated. - Approval probability is computed in code. - Held-out evaluation cases are never used to tune prompts or rules. - Evaluation claims include a leak-probe result and are demonstrations, not statistical proof. Team FirstCycle A project about making first-cycle FDA review reasoning clearer, more traceable, and easier to evaluate.
TrueFoundry
ResolveMatch Evidence-backed engineering incident routing, orchestrated by TrueForge and approved by a human. Start with START_HERE.md. Architecture React / TypeScript dashboard │ same-origin JSON API; polls persisted state ▼ FastAPI application ──────────────► TrueForge saved agent │ │ │ ▼ │ Configured model provider │ │ ◄──── authenticated MCP tools ──────┘ │ ▼ SQLite: incidents, engineers, tickets, recommendations, expiring approvals, unique assignments, audit events The agent interprets a ticket and retrieves evidence. Python ranks eligible engineers. TrueForge pauses assign_ticket; the dashboard records a version-bound approval and resumes that exact call. The assignment transaction checks the approval, engineer, team, availability, and capacity again. A unique ticket key makes repeated assignment calls idempotent. Features Incident submission and persistent queue, with retry after a failed model run. Weighted lexical incident retrieval with real supporting record IDs. Deterministic score breakdown: history 50, skills 25, remaining capacity 15, on-call 10. Eligibility filters before ranking; explicit manual review for weak or missing evidence. Primary and eligible backup; no fabricated backup when only one engineer qualifies. TrueForge run/session persistence, actual tool events, bounded execution, provider errors. Human approve/reject, server-side expiring approval, revalidation and duplicate protection. Manager and engineer views behind a persona switcher: the manager files and approves, each engineer gets a profile with their assigned queue, their own availability controls, and the resolved incidents behind their score. Team availability and on-call controls, live assignment workload, incident resolution. Searchable incident library and persistent audit trail. Input validation, parameterized SQL, separate MCP authentication, same-origin write protection, optional password sessions, security headers. Validated dataset import/export, consistent SQLite backup, container recipe, CI workflow. Structure backend/ main.py API, auth, dashboard serving, run monitor tools.py MCP tool schemas and handlers routing.py Retrieval and versioned ranking policy service.py Ticket and assignment transactions store.py Schema and database access trueforge.py Harness API adapter and approval events setup_trueforge.py Connector and saved-agent configuration personas.py Demo manager/engineer identities for the switcher seed.py Explicit synthetic seed data data_cli.py Import, export, backup frontend/src/ React dashboard and responsive styles tests/ Safety, API, integration-contract, data tests scripts/ Startup, real MCP check, model smoke test Design choices and limits Ranking uses weighted keyword overlap so results are reproducible and inspectable. It does not perform embedding-based semantic retrieval; synonyms and novel vocabulary can lower recall. The weighting and abstention thresholds are explicit initial policy, not calibrated estimates. Validate them against your own routing outcomes before making operational claims. “Routing score” and “lexical relevance” are not probabilities. Availability and capacity are hard requirements. Team can be supplied by the operator or inferred only when retrieved evidence has a clear leading team. An engineer without relevant resolved incidents cannot become the primary solely from a skills label. Historical expertise and skills can be correlated; weights need evaluation on real data. The application supports one local operator, one server process, and one workspace. The persona switcher is a demo affordance, not authentication: anyone with dashboard access can act as any persona, so the audit trail records the selected persona's name as a label rather than a verified enterprise identity. Data is persisted on disk and recoverable across restarts. It is not a multi-tenant SaaS service. There is no external Jira/ServiceNow mutation, automated remediation, vector service, or custom model training. The delivered assignment lifecycle is fully functional inside ResolveMatch's database. Development Run the Python API on port 8000. For frontend hot reload use npm run dev from frontend; Vite proxies /api to the local API. Rebuild using npm run build before serving the dashboard from the API. Keep one Uvicorn worker: the monitor and run locks are single-process. Back up using: .venv/bin/python -m backend.data_cli backup .local/backup-2026-09-19.sqlite3 The backup command refuses to overwrite existing files. Stop the app before restoring by selecting a backed-up database via RESOLVEMATCH_DB. The Docker recipe is supplied for portability; the validated path is native Python/Node. Its default Compose port binding is loopback-only. Docker-to-host connectivity to a localhost-only TrueForge process depends on the host platform; verify that connection before using the container option. Do not expose either default local service publicly. Upstream references TrueForge agent configuration TrueForge run and approval contract MCP Python SDK MCP is pinned to the supported 1.x API used by this implementation. Upgrade to MCP 2.x only with a deliberate migration and transport tests.
HackerSquadTrueFoundry
Blocks content that you don't want to see when browsing - uses jev + truefoundry
HackerSquadTrueFoundry
DXXI
VerifyFirst is an evidence-backed scam investigation agent built on TrueForge. Users can submit a suspicious message, URL, phone number, email, and claimed organization in one investigation. VerifyFirst independently checks identity, sender reputation, domains, URLs, email infrastructure, trusted sources, and suspicious behavioral signals, then correlates the evidence into a clear risk assessment and safe next action. TrueForge is the execution harness, not a wrapper: VerifyFirst uses MCP tools, native subagents, sandbox execution, durable sessions, execution traces, and human approval before exporting sensitive evidence. Key capabilities: - Multi-signal scam and impersonation investigation - Live phone reputation through IPQualityScore - URL/domain and organization verification - Email DNS, MX, SPF, DMARC, RDAP, and lookalike checks - Prompt-injection resistance for untrusted content - Evidence-backed findings with uncertainty preserved - Native TrueForge approval-gated report export - Human-readable and machine-readable evidence reports - Reproducible local and Docker setup - Automated tests and evals The goal is simple: do not ask an LLM whether something “looks like a scam.” Independently verify the evidence before a person sends money, credentials, or sensitive information.
HackerSquadTrueFoundryNext.js
LighthouseLighthouse predicts which applicants will complete a program AND come back as alumni volunteers, cheerleaders, donors and recruiters — with critical-analytical reasoning, a fairness veto, and a human on every action. Built on TrueForge. THE PROBLEM Admissions optimises for the next four years and hopes for the next forty. Nobody predicts alumni engagement; when they try, they end up predicting wealth. WHAT IT DOES Reads an applicant's own record (statement, activities, academic trajectory, institution interactions, interview notes) and produces a Long-Term Fit Report: calibrated estimates with evidence, counter-evidence and confidence intervals for five outcomes over a 10-year horizon. Reasoning follows the four pillars of Stanford GSB LEAD's Critical Analytical Thinking course: competing hypotheses, graded evidence, the cheapest falsifying experiment, and analogies to past cohorts with their limits stated. Every claim cites the input field it came from. Donor = future capacity × generosity. A trajectory prediction (ambition, persistence, reciprocity), never current wealth. A statement leaking "Atherton, my father's firm, our family foundation" is flagged as a circumstance signal and excluded — the estimate does not move. That's a live test. OBSERVE IT — three saved TrueForge agents, each run an inspectable session: critical analyst (GPT-5.5) → independent fairness auditor (GPT-5.4-mini, veto power) → action proposer. A local MCP server exposes applicant data, base rates, outcome recording and one write tool. CONTROL IT — pipeline_propose_action is @write-gated, so TrueForge pauses with Allow/Deny before anything person-affecting happens. The input schema physically rejects 20 protected attributes. Cost caps: $0.15/report, $10/eval; actual $0.054/report. Nightly TrueForge schedule re-scores every report against recorded outcomes and refreshes calibration. TEST IT — 14 Gherkin scenarios written first; 51 offline + 6 live tests passing; a traceability test fails if any scenario lacks a test. Eval scoreboard (n=30) vs base-rate baseline: beats it on every outcome; 849 evidence claims, 0 hallucinated fields; run-to-run std 0.016; recruiter ranking AUROC 0.97. Two calibration gates fail at n=30 and are reported honestly — that's what the nightly rescoring loop is for. An adversarial self-review with known limits is in the README. SCALE — domain packs swap university admissions for startup recruiting (hire/retain/refer/advocate) or corporate talent with the same analyst, auditor, gate and evals. Seasonal on-ramp: Lighthouse Coach turns the analyst toward the student's own record for families and tutors during application season. Stack: TrueForge (agents, MCP, approvals, schedules, sessions), OpenAI GPT-5.5 / GPT-5.4-mini, TypeScript, Zod, Vitest, Model Context Protocol SDK.
OpenAI GPT-5.5 + GPT-5.4-miniTypeScriptZod+3
An agent recovers a denied synthetic insurance claim on TrueForge: it reads the claim through a local MCP connector, computes the correction in the sandbox, and pauses on a shielded tool before the only call that writes. TrueForge pauses on every shielded call, including retries. That is correct, and it is also the interesting part. Each approval references one specific pending tool call, so the same business operation can be approved twice and every yes is correct in isolation. Nothing in the approval layer relates one to another. The harness authorizes a tool call; the application cares about an operation. Different units. So the memory lives where the consequence lands. The payer mints the operation id server-side and fingerprints the exact payload at prepare time, then re-verifies that fingerprint at commit. A retry of the identical payload replays the original receipt instead of writing again. A tampered amount is refused before anything is written. That check does not depend on the model behaving well. In the demo I approve twice and the ledger holds one row, same receipt. Then I ask the agent to change the amount: it refuses on its own, and the end-to-end suite shows the payer would refuse it anyway. Three operations attempted, exactly one row written. Idempotency is not new. What is new is that the thing retrying is an agent and the thing approving is a person. Relating one approval to another is an application-side concern, confirmed as such by TrueFoundry before this was recorded. Uses MCP over Streamable HTTP, Code Mode sandbox, shielded tools, and one skill (safe-resubmission) carrying the retry policy. All data synthetic; the ledger is local SQLite with immutable rows.
TrueFoundryMCP (Streamable HTTP)Node.js+2
ASports Whisperer
With AI becoming centre stage - Content and Entertainment will be the king. Sport has the highest amount of spend as industry and creates massive economic drive, so we have built an All in One - Sports Whisperer for all major sports Crickets, NFL, Soccer, Basketball, Baseball, etc where the novice and experienced players can interact with the favorite games and players !!! More details captured -
HackerSquadTrueFoundryloveable
AgentInvariantAgentInvariant is a behavioral safety evaluator for tool-using AI agents. Agent workflows are probabilistic: two requests with the same meaning can produce materially different external actions. AgentInvariant uses metamorphic testing to determine whether critical operational behavior remains consistent across meaning-equivalent inputs. For each input variant, AgentInvariant starts a fresh OpenAI conversation and an isolated SQLite database. The target agent uses real tools to check coverage, retrieve authorization requirements, record business approval, and submit a synthetic prior-authorization request. AgentInvariant records the complete structured tool trace and evaluates it using deterministic Python invariants—not an LLM judge. It verifies that exactly one submission occurs and that matching coverage and business approval are successfully recorded before submission. The evaluator is exposed through a Streamable HTTP MCP server and invoked by a TrueForge agent using the evaluate_agent tool. Results include per-variant PASS or BLOCKED decisions, ordered traces, exact invariant violations, compliance rate, and the shortest failing counterexample. The demo compares an explicitly labeled unsafe negative control, which AgentInvariant correctly blocks, with a hardened candidate that follows the required workflow. All healthcare data is synthetic. This project is an administrative workflow reliability demonstration and is not clinical decision support.
TrueFoundryPython 3.12OpenAI Responses API+5
Hardess for robo
HackerSquad
sproutsourceHarness Profiler Measures how agent harness design choices change the inference load of a coding agent, and turns the measurements into per-task rules. Everyone else benchmarks hardware with the harness held fixed. We hold the hardware fixed and vary the harness. Built on TrueForge, TrueFoundry's open-source agent harness. Read this first - PROJECT.md — what we're building, why, and the architecture - TRACE_SCHEMA.md — the contract between the two halves Layout The two halves meet only at traces/.jsonl. Neither reads the other's code. Quick start git clone && cd harness-profiler Teammate A: git checkout collector cd collector && npm install Teammate B: git checkout analyzer cd analyzer && npm install npm run analyze -- ../samples/.jsonl Working with Codex / Claude Code Both read the repo-root brief automatically (AGENTS.md for Codex, CLAUDE.md for Claude Code; both point at PROJECT.md). Open the repo and state which half you own, e.g. > I'm teammate B. Build the parser and metrics layer in analyzer/ against > samples/. Don't touch collector/.
TrueFoundry
AgentFlightAgentFlight Production Control Tower for Governed AI Agents AgentFlight is a production-minded AI operations agent built with TrueForge, OpenAI, MCP, and Daytona. Instead of treating a successful tool call as successful task completion, AgentFlight follows an evidence-first operational loop: Observe → Diagnose → Prepare → Govern → Execute → Verify → Recover/Escalate Problem AI agents can reason and call tools, but production deployment introduces harder problems: - How do we coordinate models, tools, skills, and permissions? - How do we control production-changing actions? - What happens when a tool or deployment fails? - How do we know an action actually solved the problem? - How can operators inspect what the agent did? A production agent should not report success simply because an API call returned successfully. Solution AgentFlight uses TrueForge as the agent harness around an OpenAI-powered operations agent. The agent: 1. Inspects an incident using operational evidence. 2. Separates observed facts from inferred root cause. 3. Prepares a remediation before changing production. 4. Exposes the proposed action and risk. 5. Executes production changes through MCP tools. 6. Evaluates post-deployment health evidence. 7. Declares success only when verification confirms recovery. 8. Stops or escalates when execution or verification fails. Architecture User / Incident Request ↓ TrueForge Agent Harness ↓ OpenAI Reasoning ↓ AgentFlight Operations Skill ↓ MCP Operations Server ├── inspect_incident() ├── prepare_fix() └── deploy_fix() ↓ Post-action Verification ↓ Resolved / Stop / Escalate TrueForge Integration TrueForge provides the orchestration layer for AgentFlight: - OpenAI model execution - Agent instructions and operational skill - MCP tool integration - Daytona sandbox support - Agent sessions and execution visibility - Tool-call and outcome inspection - Runtime configuration The custom agentflight-operations skill defines the evidence, remediation, execution, verification, and failure-handling workflow. MCP Operations Tools inspect_incident Read-only investigation of production evidence including error rate, latency, database utilization, logs, and deployment context. prepare_fix Creates the proposed remediation and risk assessment without changing production. deploy_fix Represents the production-changing operation and returns deployment and post-deployment verification evidence. Evaluation Scenarios INC-204 — Successful Recovery Initial evidence: - Error rate: 18.7% - p95 latency: 4.8 seconds - Database pool utilization: 100% - Connection pool size: 20 AgentFlight identifies database connection pool exhaustion and prepares an increase from 20 to 40 connections. Post-deployment verification: - Error rate: 18.7% → 0.8% - p95 latency: 4.8 s → 620 ms - Database pool utilization: 100% → 51% Result: RESOLVED INC-500 — Deployment Failure The remediation is prepared, but the deployment provider times out. AgentFlight: - Does not claim deployment success - Reports DEPLOY_PROVIDER_TIMEOUT - Confirms production was not changed - Does not fabricate verification evidence - Stops safely and escalates Result: STOP / ESCALATE INC-501 — Successful Deployment, Failed Outcome The deployment API succeeds, but post-deployment health becomes worse: - Error rate: 18.7% → 21.4% - p95 latency: 4.8 s → 5.2 s - Database pool utilization: 100% → 100% AgentFlight recognizes that deployment success is not remediation success. Result: UNHEALTHY — ESCALATE / CONSIDER ROLLBACK Key Differentiator Execution success does not equal outcome success. AgentFlight verifies the operational outcome of an agent's actions before declaring the objective complete. This pattern can extend beyond incident response to infrastructure, software engineering, finance, support, security, and other enterprise agents where actions must be observable, controlled, and verified. Built With - TrueForge / TrueFoundry - OpenAI - Model Context Protocol (MCP) - FastMCP - Python - Daytona Sandbox - GitHub Repository Author Hossam Elshahaby
HackerSquadTrueFoundryOpenAI+5
Live end-to-end fleet remediation on TrueFoundry: Vercel DVIR UI â MCP Gateway (fleet-demo-mock) â ChatGPT + Claude + Grok as three harnesses on one governed channel â with approval-gated writes and full traces. Solution: FleetHeal is a production-shaped agent harness, not a chat toy. Inspectors submit defects, including crack-related flags, in a live Vercel UI. TrueFoundry MCP Gateway hosts fleet-demo-mock and live-reads the store via FLEETHEAL_API_BASE= ChatGPT, Claude, and Grok connect as separate harnesses to the SAME gateway; model choice is swappable while governance stays central. Read tools (open defects, DVIR, vehicle/telematics) are least-privilege. ground_vehicle and other writes pause with approval_required until a human approves. Investigator is read-only; Remediation is gated + sandboxed; Reviewer independently checks policy. One defect = one durable session with traces. How TrueFoundry is used / controls: - One governed MCP Gateway channel for ChatGPT, Claude, and Grok - Hosted stdio fleet-demo-mock â live Vercel fleet API - Approval gates on writes; session continuity and observability/traces - Least-privilege read vs write tools; sandbox + independent Reviewer - Second UI submission appears on the next agent ask with no MCP redeploy Demo script: 1. Open and submit a crack-related DVIR. 2. In ChatGPT (MCP connected), ask for crack/open defects today and show TrueFoundry tool calls; optionally repeat in Claude/Grok. 3. Ask to ground TRK-4821 and show the approval_required pause. 4. Submit a second defect, ask again, and show it without redeploying MCP. Links: Live UI | Repo | MCP fleet-demo-mock with FLEETHEAL_API_BASE= | Demo video: recording in portal
TrueFoundryMCPApp+2
