Working model
What belongs in this system
Useful AI engineering begins with the product responsibility, not the model label. Retrieval, agents, integrations, and developer tooling each solve different problems and need different controls, evaluation methods, and operating boundaries.
Use the smallest capable architecture
Prompting, retrieval, deterministic workflows, and agents form a ladder of complexity. Move upward only when the product requires it.
Evaluate the complete system
Model quality matters alongside data handling, tool permissions, source attribution, failure recovery, latency, and human escalation.
Keep integrations bounded
MCP servers, EHR connections, and AI vendors should receive only the permissions and context needed for a specific workflow.
Recommended path
Start with the boundary, then go deeper
Use the first guide to establish the architecture and vocabulary for the topic.
Move into implementation details for the telemetry, data, cloud, or integration surface you own.
Turn the guidance into reviewable decisions, tests, and operating evidence for your team.
Search intent
Questions this collection answers
- When does a product need RAG, agents, deterministic workflow, or simpler automation?
- How should healthcare AI vendors be evaluated when PHI may be involved?
- Which MCP and developer tools are useful without expanding unnecessary access?
05 field notes
Read the collection
- Why Vibe-Coded Healthcare Apps Are Not Automatically HIPAA-Compliant
A practical, source-backed guide to BAA scope, PHI data flows, safeguards, cloud architecture, operations, and safe prototyping with AI coding tools.
- AI Agents vs RAG: What's the Difference (and When You Need Both)
A practical breakdown of what each actually does, when to use which, and how they combine in production.
- Best MCP Servers for Developers: Cursor, Claude Code, and Codex
A practical guide to useful MCP servers for Cursor, Claude Code, and Codex, including GitHub, Playwright, Context7, Serena, security, and setup choices.
- Evaluating Healthcare AI Vendors Under HIPAA and BAA Constraints
A practical engineering framework for evaluating AI services that may create, receive, maintain, or transmit protected health information.
- Planning My First SMART on FHIR Integration
A planning guide to SMART launch context, OAuth and PKCE, scopes, token boundaries, backend services, FHIR compatibility, testing, and PHI-safe operations.
How I can help
Turn the guidance into a production plan
Architecture review
Map the system boundary, data flow, cloud services, deployment path, and operational risk.
Vendor and BAA stack review
Separate contract coverage from product configuration, enabled features, retention, and subprocessors.
PHI data-flow review
Identify where sensitive data can appear in storage, logs, analytics, AI tools, email, support, and exports.
Production readiness
Turn decisions into controls, tests, runbooks, monitoring, access reviews, and release evidence.
AI patient history platform · AI engineering services
Discuss a projectPlease do not send patient information, PHI, credentials, or private system details through the form or by email.