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?
04 field notes
Read the collection
- 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
Notes from planning a first SMART on FHIR R4 integration and the architecture and product questions involved.
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.