AI is optional — and it never touches your messages
MessageFoundry is a modern, secure healthcare interface engine — powerful and fully capable on its own, with no model anywhere in the message path. Whether you use AI is entirely your choice: an optional aid at the keyboard that speeds up the work and never touches your messages.
AI shows up only at the keyboard, as an optional coding aid. It works through whatever model you've already set up in your editor — Copilot, Claude, and others — so MessageFoundry bundles no AI vendor and ships no keys. It helps write and edit the Python that drives each feed, with a developer reviewing every line.
We build MessageFoundry's own feeds this way too. Prefer to skip AI entirely? Guided wizards and plain Python do the same job.
Optional, always
Switch AI off entirely and nothing about how MessageFoundry runs changes. Guided wizards and plain Python build and operate every feed without it.
No AI in the message path
The engine moves, routes, and transforms messages with ordinary code. No model runs a feed, sits between your systems, or is needed to start one.
Your messages never reach a model
The engine never sends message traffic to an AI. The coding assistant only ever sees the Python you're editing — never a message body, never PHI.
A chat assistant that speaks MessageFoundry
The MessageFoundry VS Code extension is optional. Install it and you get a @messagefoundry chat participant — ask it about an interface in plain language, and because it's primed with MessageFoundry's real Router and Handler API, its answers and drafts use the actual msg[...] and Send(...) surface, not generic, almost-right guesses.
Each request goes straight from your editor to your provider — the engine is never in the loop.
The chat is one part of the MessageFoundry editor — see the whole editor →
Slash commands, primed with the API
/explain— walk through what a router or handler does, in plain language./transform— draft a@handlertransform from a description of the mapping you need./review— get a review of the handler you're writing, against the real MessageFoundry API.
More commands are in progress. Provider-agnostic by design — you bring the model; MessageFoundry holds no keys.
Your logic becomes plain, reviewable Python
Legacy engines lock integration logic inside proprietary scripts and GUIs — JavaScript channels, Tcl, ObjectScript, XML buried in a database. Porting it by hand means relearning each system and rebuilding interface by interface.
MessageFoundry's configuration is code, so the assistant can do the mechanical translation for you: paste a legacy channel or open its export, and it drafts the matching inbound / outbound Connections, a @router, and the @handler transforms in Python. You stay in control — every line lands as a diff you read, adjust, and approve.
What the assistant can draft for you
Point it at one legacy channel and it writes a first-pass version of each piece in Python — yours to read, adjust, and approve before anything runs:
- Connections — MLLP, TCP, X12/EDI, HTTP/REST, SOAP, FHIR REST, database, and file endpoints (local and SFTP/FTP/FTPS) mapped from your existing source/destination config.
- Routing — a
@routerthat mirrors your channel's filter and routing rules. - Transforms —
@handlerfunctions that reproduce field mappings and reshaping as pure Python. - Tests — starting points for harness scenarios so you can prove parity before cutover.
The same interface, two eras of tooling
The legacy way
- Logic locked in a proprietary language (JavaScript, Tcl, ObjectScript) and a vendor GUI.
- Configuration exported as XML or held in a database — hard to diff or review.
- Migration is manual re-platforming, channel by channel, by scarce specialists.
- Testing and promotion live in separate, proprietary tooling.
The MessageFoundry way
- Logic is plain Python in your git repository — read it, diff it, own it.
- The AI assistant drafts that Python from your legacy logic, in your editor.
- Review as a pull request; dry-run in the included test harness on synthetic data.
- Stage → Promote to a running engine — no separate platform to learn.
From legacy channel to running route
Point the assistant at your legacy logic
Open or paste an existing channel — a Mirth transformer, a Cloverleaf Tcl proc, a Rhapsody filter. That's source code, so it stays within the assistant's code-only scope.
It drafts the MessageFoundry equivalent
You get Python Connections, a Router, and Handlers that mirror the original's routing, filtering, and field mapping — wired by name, ready to read.
Review it like any code change
The draft lands as a diff in your editor and your pull request. Adjust, comment, and approve — the migration is now a normal review, not a black box.
Prove parity in the test harness
Dry-run synthetic, PHI-free messages through the new route and compare before/after. The headless scenario runner keeps the check green in CI.
Stage → Promote, then repeat in parallel
Promote the verified route to a running engine. Because each interface is independent code, a team can migrate many channels at once instead of serially.
PHI-safe by construction — never your messages
Safety is enforced in the code path, not left to a policy promise. The assistant only ever sees your code and the names in your config graph (connections, routers, handlers) — never a message body, never patient data — whatever model or provider sits behind it. On top of that, whoever runs the install sets one central policy that every workstation honors.
Code-only, by construction
- Only code, never messages — the assistant sends your code plus the config-graph names, and nothing else. No message bodies, no patient data, regardless of the model or provider behind it.
- Bounded context — what it sends is capped (default 8,000 characters, tunable), and any truncation is line-aligned and clearly marked.
- On-prem, localhost-first — the engine binds to
127.0.0.1and requires auth; nothing leaves the workstation through the assistant.
Your model, centrally governed
- Your model, your agreement — bring whatever you've set up in VS Code (e.g. GitHub Copilot under your own HIPAA BAA). MessageFoundry bundles no model and holds no keys.
- Hard kill-switch — ops/admin sets the policy per install; a central
offis honored on every workstation and can't be overridden locally. - RBAC-gated — an
ai:assistpermission controls who may use it, deny-by-default like the rest of the engine. - Fails safe — the editor checks the policy before every request and disables the assistant rather than guess.
Migrating doesn't expose patients. Channel logic is code, and code is all the assistant sends. Your historical messages and live PHI never go to a model during a migration — the work happens entirely on the integration logic.
Bring your interfaces into the modern era
Open, Python, and AI-assisted — migrate off a legacy engine without a re-platforming project.