DEV Community: Alex Natskovich

Top Agentic AI Development Firms Through the Lens of Implementation Type

Alex Natskovich — Thu, 26 Mar 2026 18:12:16 +0000

If you're evaluating agentic AI vendors right now, the market can feel crowded in a hurry.

Part of the confusion comes from timing. Capgemini says only 14% of organizations have deployed AI agents at partial or full scale so far, while 23% are still in pilots and 61% are still exploring. At the same time, it expects blended human-and-agent teams to become far more common by 2028. So most buyers are making decisions before the category has fully settled down.

That usually means the first question is "Who can get this into production without turning it into a science project?"

For most teams, agents start in narrow operating tasks. Finance teams try invoice extraction, PO matching, exception handling, and draft ERP posting. Support teams start with ticket classification, CRM lookups, KB retrieval, routine case handling, and escalation summaries. Engineering teams start with codebase search, test drafting, release notes, and CI-adjacent delivery work.

Then things get harder.

Once the workflow crosses systems, approvals, permissions, and state, you're no longer buying a chatbot. You're buying orchestration, controls, integration work, and a delivery team that knows how to keep the whole thing observable after launch.

Here's how I’d map the seven vendors in this comparison.

First, the buckets

I don't think these companies all compete in the same lane.

A better way to read the market is to split it into three groups:

enterprise-heavy teams that are stronger when the work touches ERP, CRM, internal data, approvals, and long-running workflows
product-oriented teams that are stronger when the goal is to ship AI into software products
model-and-domain-focused teams that are stronger when the hard part is adapting the LLM layer to your data, terminology, or deployment constraints

That framing makes the differences easier to see.

1. Enterprise-heavy delivery

N-iX

N-iX looks strongest when the project lives inside a large internal environment and the agent has to do more than answer questions.

In this comparison, N-iX reads like a fit for buyers who need agents connected to internal knowledge, business systems, permissions, monitoring, and controlled execution paths. That's the kind of setup where an agent may retrieve internal context, move work across multiple steps, call several systems, then stop for review before something important changes.

If your use case depends on integration depth, longer workflows, and production controls, this is the lane where N-iX stands out.

Itransition

Itransition sits in a similar neighborhood, but with a broader transformation feel around it.

The value here is less about one narrow agent feature and more about fitting assistants, retrieval, and workflow automation into a larger delivery model. In practice, that matters for environments where AI is one layer inside a bigger modernization effort. Think insurance operations, telecom workflows, enterprise support, invoice handling, or API-driven back-office work.

If your organization wants a provider that can place agentic workflows inside a wider systems program, Itransition makes sense.

2. Product teams that want to ship

MEV

MEV is one of the more product-minded entries in the list.

What comes through in the source material is a focus on getting agentic workflows into working software, not leaving them at slide-deck level. The architecture signals matter too: staged execution, role-based agents, validation, observability, routing, permissions, and production monitoring. That points to stateful systems where the agent has to move across tools, preserve context, and stay debuggable after release.

If you're building a data-heavy product and want agent behavior that can be inspected, tested, and improved over time, MEV looks like a strong fit.

10Pearls

10Pearls feels well suited to teams that want to move from idea to proof of concept without spending months in discovery.

Its positioning leans toward product engineering with AI folded into the work, not parked in a separate innovation track. The practical strength here is pace: assess the data and infrastructure, test a narrow use case, add verification layers, measure output quality, then decide whether the feature deserves a wider rollout.

That makes 10Pearls a good option for product teams that want an early POC, but don't want the POC to become a dead end.

Coherent Solutions

Coherent Solutions fits buyers who already have software ecosystems in place and want AI woven into them.

In this comparison, the company comes across as a strong fit for conversational systems, AI-assisted content features, analytics layers, and enterprise integrations that sit inside existing products or platforms. The key point is that the agent layer isn't treated as an isolated feature. It's part of a larger application environment, connected to services, data sources, and operational tools.

If the goal is to embed agent behavior into software you already run, that profile is useful.

3. Cross-stack and domain-heavy work

Saritasa

Saritasa is the outlier in a good way because it sits at the intersection of AI, applications, and connected systems.

That matters when your agent doesn't live only in a browser tab. In projects with device data, telemetry, voice interfaces, or field workflows, the job is often to interpret signals, surface context, trigger actions, and hand the right information to a human operator. Saritasa’s profile lines up with that cross-stack work.

If your use case touches web, mobile, and physical systems in one flow, Saritasa is easier to place than some of the others here.

Belitsoft

Belitsoft looks strongest when the model layer itself needs tailoring.

Some teams don't start with orchestration as the hardest problem. They start with domain language, proprietary data, fine-tuning, prompt design, deployment constraints, or on-prem requirements. Belitsoft’s profile fits that shape. The emphasis is on LLM adaptation first, then assistants and agent workflows built on top of it.

That makes it a good fit for buyers who need domain-tuned assistants and custom model behavior without going all the way to a large enterprise integrator.

Quick map

Vendor	Best fit	What stands out
N-iX	Large enterprises with heavy internal integration	Multi-step workflows tied to business systems and controls
MEV	Product teams shipping agentic features	Staged orchestration, observability, production-minded stack
Itransition	Complex enterprise programs	AI as one layer inside a larger systems transformation
10Pearls	Fast-moving product organizations	POC-to-rollout path with verification and release discipline
Coherent Solutions	Existing software ecosystems	Embedded AI inside products, platforms, and enterprise apps
Saritasa	Web, mobile, IoT, and voice-connected workflows	Agents operating across software and device contexts
Belitsoft	Domain-heavy, LLM-centric projects	Fine-tuning, custom assistants, internal-data grounding

What I’d ask before choosing any of them

A polished demo won't tell you enough.

What matters more is how the team handles five questions:

1. How do they orchestrate work?

Microsoft’s latest agent architecture guidance treats patterns like sequential flows, concurrent workers, group chat, handoffs, and human-in-the-loop review as first-class design choices. That’s where the category is heading: fewer vague claims about autonomy, more explicit workflow design.

2. What happens when the agent can take action?

This is where a lot of excitement falls apart. NIST’s 2026 RFI on AI agent security zeroes in on systems that can affect external state, and it calls out the need to constrain and monitor agent access in deployment environments. Once an agent can update records, trigger a workflow, or touch money movement, the design bar changes fast.

3. How portable is the tool layer?

MCP matters here. In late 2025, Anthropic donated the Model Context Protocol to the Linux Foundation’s Agentic AI Foundation, where it joined AGENTS.md and other founding projects under neutral governance. For buyers, that matters because the next lock-in risk may sit in the runtime and tool interface layer, not only in the model provider.

4. Can they survive legacy systems?

This is still the dividing line. Deloitte’s 2026 Tech Trends report says only 11% of surveyed organizations had agentic systems in production and points to legacy integration, data architecture constraints, and governance gaps as major blockers. So the winning vendor isn't the one with the flashiest agent demo. It's the one that can connect to your systems without making the rest of your stack harder to run.

5. Do they know where not to use agents?

Gartner’s warning is worth keeping in view: it predicts that more than 40% of agentic AI projects will be canceled by the end of 2027 because of cost, weak business value, or poor risk controls. At the same time, Gartner still expects agentic AI to show up in 33% of enterprise software and influence 15% of daily decisions by 2028. That combination tells you something useful: this market will grow, but lazy deployments will get exposed.

Final take

If I were shortlisting vendors in this category, I'd start with workflow shape, not brand recognition.

If the hard part is internal systems and controlled execution, I'd look first at N-iX or Itransition.

If the hard part is getting agent features into a product with solid observability, MEV, 10Pearls, and Coherent Solutions make more sense.

If the hard part is custom model behavior, proprietary data, or cross-stack delivery across apps and devices, Belitsoft and Saritasa become easier to justify.

The broader shift feels pretty settled by now. Agent development is turning into workflow engineering with LLMs inside it. The teams that win over the next couple of years will be the ones that can connect tools, permissions, traces, approvals, and business systems without losing control of the runtime.

Technical Due Diligence for Small Acquisitions: A Developer’s View

Alex Natskovich — Mon, 02 Mar 2026 16:44:01 +0000

Technical due diligence sounds like something for bankers and lawyers, but a lot of the work sits with engineers. If your company is looking at buying a small product or platform, at some point someone will ask you to look at the code, the infrastructure, and the team and say whether the deal makes sense from a technical side.

In practice you usually want answers to three basic questions:

What are the main technical risks in this system?
How do those risks affect what the buyer is paying and expecting?
What work will the engineering team have to do after closing?

This is a look at those questions for SMB-scale deals from a developer’s point of view.

SMB vs Enterprise: Same Idea, Different Scale

Most public material on tech DD comes from large deals: private equity, corporate roll-ups, multi-region IT. That setup assumes many systems, many teams and months of coordinated work.

A small acquisition is different.

Often there is one core product, a primary codebase and a small engineering team. Instead of working only with a data room, you can usually get read-only access to the repository, to the main cloud account and to monitoring dashboards. You can speak directly with the people who built the system. That makes the work more hands-on and less about documents.

Because the scope is smaller, you go deeper. You read the code and see how it is structured. You look at the data model and how hard it is to change. You trace a feature from commit to production to understand deployment and release. You check what monitoring and alerting is in place and how incidents are handled. You also confirm basic points like IP ownership and key third-party licences.

Time and budget follow this pattern. Enterprise DD can run for months and involve several teams. For SMBs, two to four weeks is common. If the DD budget grows to the size of a full-time salary for a small deal, the process is probably overbuilt.

Integration is narrower too. You are not planning a full IT merger. The questions are more direct: can this product authenticate against your current identity provider, can you move or sync data without rewrites, can you run it alongside your existing stack for a while.

Red flags land differently. In a small company, a single developer holding most of the knowledge, missing IP assignment, or a production setup with no backups can be enough to change or stop the deal. In larger companies, you see broader but more distributed problems: old architectures, mixed security practice, partial compliance. Those often lead to discounts and integration plans rather than an immediate no.

If you are the engineer involved, your main job is to keep the scope honest: small deal, focused DD; and to make sure the findings stay tied to the business decision, not just to technical taste.

Who You Bring In (and Why)

You can do some of this yourself, but many buyers bring in a firm that runs technical DD as their main work. These firms are not all the same. It helps to think in types rather than in brand names.

Some, like MEV, act much like external engineering leads. They read architecture, infrastructure and code, then link what they see to delivery speed, stability and integration effort. They are useful when the main concern is whether the product can support the growth case and how much work it will take to make it fit your environment.

Others have a background in testing and software quality, such as System Verification. They pay attention to coverage, test strategy, environments and release practices. They fit deals where long-term reliability and support cost are central.

In regulated sectors you see firms like Techrivo. They mix technical checks with detailed work on security controls, data handling and process maturity. They are relevant when a mistake does not just lead to downtime but to audits and fines.

Some groups, for example Liberty Advisor Group, look at IT and business together. They connect technical risk to operations and financial exposure. That is useful when the target depends on shared systems like ERP or when the finance team wants a direct link between technical findings and the model.

There are also providers tuned to early-stage companies, such as Upsilon IT, which use structured frameworks to assess team practices, scalability limits and immediate debt; benchmark-oriented firms like Crosslake Technologies that compare what they see with data from many past deals; and engineering-heavy shops like Mad Devs that focus on deep code and infrastructure review.

Beyond that, there are more specific specialists: Vysus Group works in industrial and asset-heavy environments; Zartis often appears in European cross-border deals; VisionX looks closely at AI and ML claims and checks whether the systems behind them are real and maintainable.

The point is simple: decide what sort of risk matters most in your deal—code quality, reliability, compliance, integration, AI, industrial systems—and pick a firm whose normal work lines up with that area.

What a Useful DD Report Looks Like

Whatever firm you work with, the output should help you and your leadership make decisions and plan real work. A large slide deck with vague comments is not enough.

The report should start with a short summary that a non-technical reader can follow. It should say whether anything blocks the deal, which issues change what the buyer should pay, and what needs attention in the first year. If someone on the business side can read only this section and explain it back, it is doing its job.

Each major finding below that should answer four plain questions: what is the issue, why it exists, what it does to the business and what to do about it. For example, if a service cannot scale beyond a certain point, the report should say whether this comes from design, implementation or infrastructure limits, and what that means for the planned customer or data growth.

You will also need rough ranges for effort. Nobody expects exact estimates from a DD team, but it matters a lot whether a fix is measured in weeks or years, and whether you need one engineer or several. Without ranges, you cannot connect findings to valuation or to post-deal staffing.

A good report also suggests order. It should be clear which issues need work in the first ninety days, which belong in a one-year plan and which can wait. Many teams use the report as a starting point for their roadmap.

Finally, the report should show how the conclusions were reached. References to parts of the codebase, infrastructure diagrams, log samples and notes from interviews make it possible for your own engineers to verify and extend the work later.

Here is a simple test for any DD report:

you can turn its findings into concrete tickets,
you can see how those tickets link back to cost and risk,
you can trace each major claim back to some piece of evidence.

Working With a DD Provider

Even a strong provider will produce weak results if the engagement is set up badly. Three things matter most: objectives, access and communication.

Start by writing down what you need to decide. Common examples: can the platform handle the growth in the business case, are there any security or compliance gaps that would block use, and will integration into your stack cost more than planned. Share this with the provider and ask them to frame the work and the report around these points.

Next, organise access. For small deals this usually means read-only access to the main repository, to cloud accounts or dashboards, to incident and uptime records and to the people who know how the system behaves. If the provider only sees prepared slides and policy documents, you will get generic output.

Finally, agree on how you will talk during the engagement. Short, regular check-ins let you catch misalignment early. If they are spending days on a component you plan to replace soon after closing, you can redirect them.

Throughout, ask them to keep translating into business terms. For each major issue, ask what it does to valuation, operating cost and integration timing. That is the layer your leadership will use when making decisions.

Three questions help when you are choosing or steering a provider:

How will your findings change our model or integration plan?
Who on your team has built and run systems similar to this target?
What should our engineering team do differently in the first ninety days after closing because of this report?

If they can answer those clearly, the work they produce is more likely to be useful to both engineers and the rest of the company.

The Real Reason Vendor Teams Slow You Down (And How to Fix It)

Alex Natskovich — Thu, 22 Jan 2026 15:26:07 +0000

The story usually starts the same way.

You bring in an external team. You create accounts. They get access to:

the monorepo,
a Jira project,
maybe a Slack channel called #vendor-xyz.

A week later, code is flowing. Branches appear, PRs open, standups are happening.

Then you get the first set of questions:

“Where should I read the requirements for this story?”
“Who signs off if this change breaks another team’s API?”
“Which staging environment mirrors production?”

And you realise you never answered those properly. You just gave them Git access and hoped for the best.

The integration problem no one owns

Most teams treat “integration” as wiring: accounts, boards, repos, VPN. Once those are done, everyone assumes things are “set up”.

But the things that make or break the next quarter are much more boring:

where product context lives day to day,
who answers which kind of question,
how code moves from PR → staging → production when multiple teams are touching it,
who owns edge cases, tests, and incident response.

When those stay fuzzy, people still ship. But the work doesn’t join up.

You get:

more handoffs,
more waiting,
more “oh, I thought you were handling that part”,
and bugs that appear late because assumptions didn’t match.

Ownership becomes a weird grey zone between “the internal team” and “the vendor”. Which usually means: nobody.

What weak integration looks like in a repo

Here are a few patterns I’ve seen repeat across different companies and vendors.

1. Duplicate work
Two tickets, slightly different wording, describe roughly the same change.

One team adds a validation rule in the frontend form.
Another team ships a different rule in the API.

QA hits the endpoint, sees inconsistent behaviour, and asks which one is correct. The “answer” is buried across:

a Slack thread,
a Figma comment,
and a PR description.

Everyone did something logical from their point of view. The integration work was simply never made explicit.

2. Priority drift
Internally, you’re planning against a roadmap theme: “finish migration to new billing system this quarter”.

The external team, meanwhile, is just burning through whatever hit their backlog. Nobody ever connected their queue to your roadmap, so they’re shipping useful things… just not the things that unblock the main goal.

On status reports, both teams look busy. The initiative itself keeps slipping.

3. Review and environment friction
You see this in three places:

PR reviews:
A big change opens against main. Internal devs assume the vendor leads will review. Vendor leads expect internal maintainers to own the final check. PR sits for days.
Environments:
The “staging” the vendor tests on doesn’t match the “staging” your internal team trusts. Different configs, different feature flags, sometimes a different database snapshot.
Dependencies:
A critical integration point shows up late because one team assumed “the other side” owned that boundary. Nobody wrote it down.

None of these are huge on their own. Combined, they slow everything down and crank up the anxiety around every release.

4. Trust slowly leaking away
This part sneaks up on you.

Internal leads start reading vendor PRs with more suspicion. They leave more comments, ask for more screenshots, request extra tests.

Vendor engineers notice that questions take a while to get answered, so they stop asking as much. They guess more, ship more partial-context changes, and hope it’s right.

Feedback loops stretch. Everyone is slightly on edge around release time. The roadmap deck looks fine; the feeling on the ground does not.

And then your roadmap stops matching production

On slides:

Q1 goal: Ship X
Q2 goal: Extend X with Y

In production:

Part of X is live in one region,
Another part only exists behind a feature flag,
Some critical glue is still on someone’s Trello board.

When you do release reviews, the same pattern appears:

integration pieces missing,
dependencies nobody tracked,
QA responsibility split across “whoever had time”.

Planning meetings become stitching sessions: trying to reconcile what was planned with what emerged from two partially aligned teams.

Give that a couple of quarters and the roadmap isn’t a guide anymore. It’s a narrative you write afterwards to explain whatever happened.

Why I ended up writing a Team Integration Workbook

After watching this happen a few times, I stopped blaming “bad vendors” and started looking at the first 30–60 days.

Those first weeks are where:

people are still open to changing habits,
process isn’t calcified,
everyone is being polite and optimistic.

And yet that’s exactly when teams postpone decisions like:

who approves releases,
who owns which repos and which parts of the system,
where product context is kept (and updated),
how breaking changes are proposed and rolled out,
what “done” means when there are two orgs involved.

To save myself from re-doing this from scratch every time, I started collecting the questions and templates that helped.

Over time that turned into a Team Integration Workbook: a set of canvases, checklists, and workshops you can run with internal and external leads.

This is aimed at the people stuck between engineering and delivery: CTOs, VP Eng, Heads of Product, programme managers, tech leads who are about to be responsible for “making the vendor work”.

Here’s what’s inside, roughly.

What’s in the workbook

Nothing fancy. No frameworks with cute acronyms. Just stuff I’ve seen teams need again and again.

Integration maturity model

A one-page way to answer: “Where are we already leaking?” across:

planning,
reviews,
releases,
access,
ownership.

The point is to make both teams describe today the same way. Even “we’re in bad shape” is useful if everyone agrees on where.

Kickoff checklist + team charter

These are the questions that sound boring but pay off in weeks:

Who can merge to protected branches?
Who approves releases, and for which services?
Where do requirements live, and who keeps them up to date?
How are questions asked (thread, issues, office hours) and who responds?
What does escalation look like when something blocks delivery? You run this once at the start with people who can actually make decisions.

Roles and responsibilities workshop

This is where implied ownership dies.

You explicitly assign owners (by person or role) for things like:

API contracts and schema evolution,
test coverage standards (unit, integration, E2E),
incident response and on-call,
monitoring/alerting,
integration points between systems,
regression checks after big changes.

The awkward part is the point: better to have that conversation at the start than in the middle of an incident.

Shared roadmap, risks, and planning rhythm

A light shared view so the vendor’s backlog points at the same targets as your internal roadmap.

shared dates,
shared definitions of milestones,
a spot to write down known risks and dependencies.

Plus a simple template for the planning cadence you’ll both use.

Health check + joint retro

A small repeatable format (takes ~30–45 minutes) for:

“what felt slow lately?”,
“what was unclear?”,
“what surprised us?”,
“what should we change in how we work together?”.

Use it while changes are still cheap, instead of waiting for a quarterly review where everybody is already frustrated.

A 30–60 day flow you can copy

Whether you use this workbook or roll your own version, the flow is basically this:

- Get a shared baseline.
Sit down with leads from both sides and agree on where integration is already painful: planning, reviews, releases, access, ownership. Write it down.

- Name your scenario.
Is this:

a full external squad fully owning a domain?
a few engineers embedding into existing teams?
a contained project with a narrow API surface?

The answers to “who owns what” are different in each case. Make sure your setup reflects that, not some generic vendor checklist.

- Run a real kickoff (not just intros).
In one session, decide:

who approves releases to which environments,
who reviews which repos,
where requirements and specs live,
how to propose and roll out breaking changes,
what “done” means across both teams.

Capture it in a charter you can send to every new person who joins later.

- Agree on a shared planning rhythm.
Pick a cadence that both sides stick to (weekly, biweekly) and tie it to the same milestones. Internal sprint reviews and vendor demos should point at the same goals, not parallel ones.

- Do tiny health checks every couple of weeks.
Nothing huge. Just a recurring slot where you ask:

what was painful in the last iteration?
what was unclear?
one thing we’ll change in how we collaborate?

Tweak early instead of after six months of accumulated friction.

Closing thoughts

If you’ve worked with external teams for a while, you know that people can be busy, tickets can be moving, and yet the output doesn’t line up with what you intended to build.

That doesn’t come from one big mistake. It comes from dozens of small, unmade decisions in the early days of the relationship.

You don’t need a massive process overhaul for this. You just need a deliberate pass over ownership, decision paths, and delivery flow while things are still fresh.

That’s why I put the Team Integration Workbook together>>> https://mev.com/blog/team-integration-workbook-practical-playbook-to-plug-external-teams-into-your-delivery-system Use it (or your own equivalent) in the first weeks with a vendor: run the sessions, write things down, set a shared rhythm, and keep checking in before the collaboration drifts.

If you’re curious, grab the PDF, run a kickoff with the people who can make the calls, and see what changes in the next release or two.

Why 80% of Healthcare AI Pilots Die in Pilot: The Data Architecture Problem

Alex Natskovich — Mon, 15 Dec 2025 13:13:16 +0000

Healthcare data is a mess. You’ve got EHRs, labs, pharmacies, payers, and assorted vendors all speaking slightly different dialects of “almost-FHIR, sort-of-HL7, random CSV, and mystery XML”. On top of that, there are duplicates, missing fields, and business rules that only exist in someone’s head.

Drop a powerful LLM on top of that and you don’t get magic. You get unstable behavior, unsafe recommendations, and a project that never makes it out of “cool internal demo” mode.
If you want AI to do anything useful in healthcare, you need to fix the data layer first.
In this post, I’ll walk through how we at MEV approach AI-ready healthcare architectures: the core layers you need, and six concrete steps to get from “scattered systems” to “LLMs that can safely act on clinical data” >>> https://mev.com/blog/a-practical-guide-on-building-an-ai-ready-healthcare-data-architecture-in-6-steps

TL;DR

Most healthcare AI projects stall because the data layer is not ready:

Data is fragmented, inconsistent, and governed by tribal knowledge instead of explicit rules.
Modern healthcare platforms tend to converge on four core layers:
- FHIR operational layer (near real-time, clinical workflows)
- Warehouse / lakehouse (analytics and ML on de-identified data)
- MDM / hMDM (identity and golden records)
- API + access control (how apps and AI touch the data)

To make that stack AI-ready, you can think in six steps:

Use FHIR-first persistence as your canonical model.
Add fine-grained authorization, tighter than normal app RBAC.
Expose tools / function calls for LLMs instead of raw API access.
Add RAG so answers are grounded in patient data instead of model “intuition”.
ETL into a warehouse for cross-patient analytics and ML.
Bake in privacy and compliance controls (tokenization, consent, logging, zero-retention LLMs).

Why AI keeps failing in healthcare

The failure pattern is depressingly consistent:

Teams start with the model (“Let’s integrate GPT with our EHR!”).
A quick prototype kind of works on a sandbox dataset.
As soon as it touches live data and real permissions, everything falls apart.

After almost two decades building software for regulated industries, the pattern looks less like an AI problem and more like an architecture problem.

The blockers usually live here:

Missing or inconsistent fields → misclassified risk, wrong triage, “why is this answer so off?”
Duplicate patients and providers → broken histories, unsafe recommendations.
Conflicting business rules across systems → AI behavior changes depending on which source you hit.
Different source formats for the same concept → fragile ETL, surprise errors.

Healthcare is unforgiving. A tiny data glitch that would be harmless in an ecommerce app can translate to bad clinical guidance. That’s why we start with the data foundation instead of the model.

The four core layers of an AI-ready healthcare data stack

Most modern healthcare platforms we see end up with some version of these four layers:

FHIR-first operational data layer

Near real-time clinical data.
Resources like Patient, Observation, MedicationRequest, Encounter, Condition share common semantics.
Systems can plug into a known structure instead of one-off schemas.

Warehouse / lakehouse analytics layer

Snowflake, BigQuery, Databricks, etc.
ETL’d, standardized data for population health dashboards, longitudinal patient journeys, predictive models on de-identified data, сost and quality analytics

MDM / hMDM (Master Data Management)

Reconciles identities across patients, providers, payers, and plans.
Produces “golden records” so everything above isn’t built on a shaky identity layer.

API + access control layer

REST / GraphQL / FHIR APIs exposed in a predictable way.
Central place for permission logic, purpose-of-use checks
Masking and redaction, auditing and field-level access controls. This is also where your AI systems should enter the picture.

With that backdrop, let’s walk through how to assemble this into something an LLM can safely work with.

Step 1: Make FHIR your operational source of truth

If you want AI to navigate clinical data, it needs a consistent language. That’s what FHIR gives you.
Using FHIR as your canonical model:

Eliminates schema chaos: patients, encounters, observations, medications, conditions all use defined resource structures instead of ad hoc JSON.
Cuts a big chunk of one-off mapping work: many vendors already expose FHIR, or can be transformed into it with stable pipelines.
Makes interoperability default: hospitals, labs, pharmacies, payers all plug into the same structure.
Gives AI tools predictable outputs: a function like get_patient_observations() always returns a list of Observation resources, not “whatever that one integration happened to send”.
Keeps you adaptable: new modules or AI tools can connect without re-inventing your data model.

Quick reality check on standards

FHIR isn’t the only standard in healthcare, but it fills a specific niche:
HL7 v2 is great for older, message-based hospital workflows.
HL7 v3 / CDA is document-centric; good for clinical documents and sharing entire summaries.
openEHR focuses on long-term clinical modeling and robust repositories.
OMOP is fantastic for research and population analytics on de-identified data.
CDISC targets clinical research submission workflows.

We normally see FHIR working alongside these, not replacing them. FHIR deals with modern, API-driven, patient-centric workflows; the others handle archival, research, or regulatory use cases.

Example: FHIR-first patient engagement and compliance platform
One of our clients needed a platform to orchestrate complex treatment programs across patients, providers, pharmacies, and admins.

We could have cobbled together a bunch of custom tables. Instead, we built the whole thing on FHIR v4:

A HAPI FHIR server managed read/write operations.
External EHR and pharmacy systems synced through FHIR APIs.
Permissions were enforced at the resource level (RBAC + relationship-based rules + FHIR security mechanisms).

The impact:

No custom schemas for core clinical data → drastically less mapping.
Multiple apps (patient, provider, admin) could reuse the same data layer.
Access controls lined up naturally with FHIR resources.
When the client started adding AI features, the data model already made sense to an LLM.

Once FHIR is in place as your operational backbone, you can start thinking about who is allowed to see what.

Step 2: Layer in fine-grained authorization

Giving an AI assistant access to clinical data is very different from building a normal CRUD app.

You don’t just want “doctor” and “patient” roles. You need a permission model that accounts for:

User-specific access (patients only see their own records, physicians see active patients under their care).
Purpose of use (treatment vs research vs billing, etc.).
Contextual rules (time-bound access, “break-glass” emergency overrides).
Full audit trails (who accessed which fields, and why).

Imagine a patient asking: “What were my last blood test results?”

Behind the scenes:

The AI identifies and authenticates the user.
The authorization layer evaluates:Is this user the patient? Are they allowed to see Observation resources for themselves?
Only authorized FHIR resources are retrieved.
The AI summarizes those observations in natural language.

Tools we’ve seen work well in this space:

Permit.io, Permify for fine-grained access control with developer-friendly APIs.
OPA / ABAC-based custom solutions when you need very specific policy logic.

The key point: all AI queries should pass through this layer. The model never “free-browses” your datastore.

Step 3: Add a tools / function-calling layer for AI

Now that you have structured data and permissions, you need a safe way for AI to interact with it.

Modern LLMs (OpenAI, Claude, others) support function calling. Instead of asking the model to generate SQL or call arbitrary URLs, you expose a small toolkit of functions.

On your side, you already have:

FHIR server (operational data)
Warehouse / lakehouse (analytics)
MDM (identity)
APIs (access)

On top of that, define a narrow set of tools such as:

get_patient_observations(patient_id, category)
get_patient_conditions(patient_id)
get_patient_medications(patient_id)
search_encounters(patient_id, date_range)

The runtime flow looks like this:

User asks a question.
The LLM picks the appropriate tool from its toolbox.
The tool: Checks permissions using your auth layer, Queries FHIR / MDM / warehouse as needed, Returns structured data.
The LLM generates a natural-language answer based on that structured result.

The model never talks to your FHIR store or warehouse directly. It always goes through a thin, well-tested layer you control. That’s where you enforce input validation, limits, and permission checks.

Step 4: Use RAG so the model doesn’t have to guess

Even with function calling, a base LLM will happily improvise if it doesn’t see the data it needs. That’s how you get hallucinated medications and made-up guidelines.

Retrieval-Augmented Generation (RAG) gives you a way to ground answers in the right FHIR resources.

For example, a patient asks: “Why was I prescribed this medication?”

You can design a flow like this:

A tool retrieves:The relevant MedicationRequest, Any linked Condition, Recent Observation resources that influenced the decision.
Your RAG layer formats those resources into model-friendly context.
The LLM receives: The user’s question, Only the necessary pieces of structured data.
The model explains the reasoning, using the retrieved resources as the anchor.

This approach has a few important privacy implications:

Inject only what you need (fields required to answer the question).
Mask or tokenize identifiers (SSNs, exact addresses, etc.).
Log every retrieval (which data was passed to the model, for which user, and for what purpose).
Use zero-retention modes for LLM providers so PHI isn’t used for training.

**The result: **patients get explanations that trace back to specific data points, and you avoid “the model just made something up” scenarios.

Step 5: ETL into a warehouse for cross-patient analytics

So far we’ve focused on single-patient interactions. But you still need population-level insight:

Quality and performance metrics
Claims and cost analytics
Cohort discovery
Predictive models trained on de-identified data

That’s where a warehouse/lakehouse comes in.
Typical pattern:

ETL FHIR (and related) data into Snowflake / BigQuery / Databricks.
Normalize schemas, map codes, add quality checks.
De-identify or tokenize as required.
Expose curated datasets for analysts and ML.

Permissions change here:

Only a small, vetted group (data engineers, analysts, admins) can touch cross-patient datasets.
AI assistants that operate on a single patient by default should not see these populations unless explicitly allowed (e.g., a separate “analytics assistant” with stricter access).

Example: Snowflake-first claims intelligence platform
One client needed to infer a patient’s drug insurer at the pharmacy counter, even when the patient presented the wrong card.
Inputs:

Huge volumes of vendor-supplied pharmacy claims
Different schemas per vendor
Frequent format changes
Sparse documentation

We built a Snowflake-first architecture that:

Ingested claims directly via Snowflake Shares.
Normalized and validated incoming schemas.
Standardized codes and filled gaps through enrichment.
Applied tokenization for identity-related fields.
Ran a multi-stage MDM flow (deterministic → probabilistic → ML-assisted) to reconcile payer, PBM, and plan into a usable “golden” structure.

Outcomes:

A unified, reliable claims repository.
Low-latency API to infer coverage in real time.
Strong privacy posture (tokenization instead of raw PII).
A robust foundation for ML models to predict payer/plan.

This same warehouse layer becomes the backbone for dashboards, risk scores, and model training pipelines.

Step 6: Build privacy and compliance into the stack

You can have great architecture and clever LLM flows and still fail if regulators can’t trust the system.
For healthcare, we treat this as a first-class requirement, not an afterthought.

Key safeguards:

Data minimization. Tools and RAG inject only what’s needed to answer a question.
De-identification for ML. Use frameworks like Expert Determination or Safe Harbor when training models on historical data.
Tokenization and encryption. Especially for identities, genetic data, and sensitive observations.
Consent enforcement. AI must respect opt-outs and purpose limitations (e.g., treatment vs marketing vs research).
Comprehensive audit logging. Capture which user or agent accessed which resources and fields, for which purpose, and when.
Zero-retention LLM modes. Configure providers so PHI isn’t stored or used for model training.

When this layer is wired into the architecture, you can ship features that make regulators, compliance teams, and clinicians a lot more comfortable with AI-driven workflows.

Putting it together: what this architecture lets you do

With these layers in place, you unlock some useful properties:

AI assistants can act on behalf of users, using their exact permissions.
HIPAA / GDPR compliance is enforced technically, not just via policy documents.
AI queries are grounded in structured clinical data and fully auditable.
Behavior is explainable: every answer can be tied to specific FHIR resources and access decisions.
You can scale by adding new tools rather than redesigning the whole stack.
You often don’t need custom models to start; high-quality LLMs plus the right structure go a long way.

Final thoughts

In healthcare, AI success is dominated by architecture, not model choice.

If your data is fragmented, your permissions are fuzzy, and your access patterns aren’t controlled, no frontier-grade model will save you. If your data is well-structured, your permissions are explicit, and your access is mediated through narrow tools, even a “boring” LLM can safely add value.

At MEV, we’ve spent close to 20 years building systems in regulated environments (HIPAA, GDPR, SOC 2, ISO 27001, shifting AI guidance). From what we’ve seen, regulation is rarely the real blocker. Sloppy architecture is.

If you’re planning an AI initiative in healthcare, tell us what you’re trying to build. We’ll walk through what it will take in terms of time, scope, and budget, and whether AI is even the right tool for the problem you have.

Building AI-Driven Real Estate Platforms: Data, Models, and Infrastructure

Alex Natskovich — Thu, 06 Nov 2025 15:14:07 +0000

Rising interest rates, thinner margins, and increasingly complex assets have forced real estate platforms to evolve from manual analysis into algorithmic systems. That shift has made AI not an operational layer — embedded in valuation engines, maintenance dashboards, and leasing workflows.

Today, PropTech teams treat data pipelines and ML models as part of their infrastructure stack. This article unpacks how those systems are built, what architecture enables them, and where the next technical frontier lies.

1. Why AI Has Become Core Infrastructure

AI no longer lives in demo decks. It processes valuation signals, automates document parsing, models energy patterns, and generates tenant interactions. What once required entire teams and weeks of work now happens in hours — continuously retrained, deployed, and integrated into production APIs.

The practical questions for engineers aren’t about “whether” to use AI, but how to architect it:
how to design the data layer, train reliable models, and manage compliance in regulated workflows.

2. Market Data and Adoption Signals

Data now drives the market

Real estate systems ingest enormous streams — tenant events, IoT sensor metrics, transaction logs, aerial imagery. Manual inspection is impossible, so ML models take over pattern discovery and forecasting.

Studies show AI could automate up to 37% of real estate operations, saving the industry around $34 billion in efficiency gains by 2030.

Investors are catching on too: AI-powered PropTech firms raised about $3.2 billion in 2024, a clear sign that confidence—and urgency—are both rising.

Next wave of value creation

Beyond automation, AI layers predictive and generative intelligence onto operations: dynamic pricing, credit scoring, asset-level forecasting, and portfolio optimization.

Generative AI alone is projected to create $110–180 billion in additional value across the real estate industry.

VTS CEO, Nick Romito:

“AI is rapidly augmenting investment, strategy, and operations in all corners of commercial real estate. Looking broadly, the largest value for AI in the industry is centered in giving teams time back to complete more of their essential day-to-day tasks that generate the most ROI for their respective businesses. With VTS AI, we focused on addressing the most critical pain-points of our customers by automating manual processes and streamlining data to not only maximize efficiency but also ensure the best data strategy.”

Timing and readiness

61% of commercial real estate firms are already running AI pilots. The modern ecosystem—cloud infra, IoT, and pre-trained ML frameworks—supports full production use.
Companies like MEV, a software development partner specializing in PropTech & Real Estate Software Development, help teams transition to AI-ready architecture through practical engineering work: upgrading MLSs, launching PropTech products, and building SaaS platforms. Their experience with RESO-certified APIs, RETS integration, and real-time data pipelines allows existing property systems to connect with AI models without sacrificing compliance or uptime.

3. Core AI Capabilities in PropTech

Modern PropTech stacks converge data engineering, ML, and automation. A typical architecture includes ingestion from MLS or IoT streams, entity resolution, feature extraction, and domain-specific model serving.

Cotality Chief Data and Analytics Officer, John Rogers:

"The value in AI isn't just in the technology—it's in the human connection it restores. By immediately handling high-volume tasks—from precise roof analytics to predictive 30-year climate modeling—our solutions deliver granular intelligence in moments. This doesn't just cut costs; it gives professionals the most valuable asset: time to sit down with their clients and use that data to counsel them on mitigation strategies, reinforce long-term resilience, and confidently design innovative policies. That's the AI difference: turning data processing into people-focused strategy."

The most common deployed features include:

Automated Valuation Models (AVMs) trained on transactions, geospatial attributes, and macroeconomic indicators generate real-time price estimates and risk-adjusted forecasts.
Predictive analytics identify demand surges, rent fluctuations, and maintenance risks.
Computer vision analyzes aerial imagery and interior recognition for use in appraisal, insurance, or marketing.
Conversational agents manage tenant onboarding, lease renewals, and maintenance triage using NLP.
Generative models create synthetic staging visuals and content for listings or reports.

ApartmentIQ/MavenAI Head of Marketing, Jeannie Cambria:

"ApartmentIQ is the multifamily rental housing industry's leading market data solution - with five years of public data and over 37 million units tracked across the country. ApartmentIQ Market Surveys provides unmatched accuracy and transparency into every market, competitor, and unit, every day. Designed to help your team make data-driven decisions that optimize revenue, refine pricing strategies, and outpace the competition, ApartmentIQ proprietary AI analyzes and validates each data point to ensure the cleanest, most accurate data set, down to the unit level at the properties you track."

TurboTenant CEO, Seamus Nally:

“We’re seeing AI shift from simply improving back-office efficiency to actually driving revenue. A great example is our AI-powered Maintenance Triage at TurboTenant. Traditionally, maintenance requests come in missing key details, leading to costly back-and-forth between landlords and tenants. Since landlords spend an average of 10 to 15% of their gross rental income on maintenance each year, resolving even one or two basic issues upfront can translate into meaningful savings. Our AI engages tenants with a few targeted questions and simple self-checks, resolving many problems on the spot. When a service call is needed, it automatically generates a complete, actionable request so landlords can dispatch the right pro without delay. It’s a powerful way we’re using AI to remove friction, save money, and solve problems proactively for landlords.”

4. Implementation: Data, Systems, and Compliance

Data architecture

The foundation of any PropTech AI system is a unified data model. Property data lives across multiple silos — MLS, IoT sensors, lease management systems, tax registries. Normalization is mandatory for ML to work consistently.

Platforms such as Cherre or Reonomy demonstrate scalable architecture patterns:

ingestion pipelines built on event-driven microservices,
schema mapping aligned to RESO or other open data standards,
entity resolution frameworks linking owners, parcels, and transactions.

Data quality remains a limiting factor. Inconsistent attributes can degrade model accuracy by 20–30%. Companies investing early in automated cleansing and versioned data governance — CoreLogic Cotality, Zillow, or CoStar — achieve faster model retraining and reduced error drift.

Change management and process design

Algorithm deployment isn’t the hard part; operational adoption is. AI outputs must integrate with existing property management and analytics tools through APIs or webhooks.

Teams evolve from interpreting raw data to supervising models, reviewing anomalies, and adjusting business rules. Retraining cycles and feedback loops become part of standard operations.

Ethical, legal, and transparency requirements

AI now influences pricing, underwriting, and tenant selection. Regulatory frameworks such as the EU AI Act classify these systems as “high-risk.” Engineering teams must implement:

documented model lineage and assumptions,
automated bias detection pipelines,
compliance-aligned data masking for GDPR/CCPA.

Explainability frameworks (e.g., SHAP, LIME) are being built into valuation and lending models to provide auditable outputs for regulators and lenders.

5. What’s Next: Convergence and Autonomy

Contextual intelligence

AI is moving from automation to self-optimizing systems that understand the correlation between market forces, building telemetry, and user behavior. Data fusion from IoT and ML enables predictive, continuous adjustment.

“Living” buildings

Solutions like BrainBox AI, Infogrid, and Facilio illustrate this evolution — models now control HVAC, lighting, and energy use in real time, adjusting autonomously based on occupancy and energy prices. Each building becomes a feedback loop where machine learning refines control policies without human tuning.

Agentic AI

Agentic models go beyond automation by combining reasoning, memory, and action. In PropTech, they already handle multi-step tasks like lease renegotiation or budget reconciliation.

Companies like Northspyre and REAi already integrate autonomous decision-making into project management and property matching.

These systems will gradually handle transactions and contract workflows with limited oversight — an operational leap comparable to the jump from static dashboards to real-time control planes.

Data consolidation and strategic control

The major players — CoStar, JLL, and CoreLogic — are racing to consolidate proprietary data ecosystems. The same principle drives MEV’s PropTech engineering work: helping clients build vertically integrated data intelligence stacks that link valuations, climate data, and spatial analytics into one pipeline.

Trust as infrastructure

Transparency and compliance maturity will define credibility. As automated valuation and lending become regulated, firms investing in explainable and ethical AI will secure the confidence of regulators and investors alike.

Conclusion & Key Takeaways

AI now underpins valuation, maintenance, leasing, and analytics. For developers and data engineers in PropTech, the challenge is designing systems that scale — technically, ethically, and economically.

Key Takeaways

Operational integration defines maturity. Treat AI as infrastructure — not an add-on.
Data foundations are strategic assets. Normalized, interoperable models make scaling possible.
Governance ensures resilience. Build explainability and auditability from day one.
Human oversight remains decisive. Use AI to accelerate judgment, not replace it.
Partnerships accelerate adoption. Teams like MEV specialize in building RESO-certified MLS systems, AI data pipelines, and SaaS architectures that let PropTech firms implement these capabilities faster — without losing compliance or control.

The next generation of real estate platforms will be built by developers who understand both code and context — translating messy data and regulatory friction into scalable, intelligent systems.

Read more about AI in PropTech & Real Estate 2025: Trends & Use-Cases >>> https://mev.com/blog/ai-in-proptech-real-estate-2025-trends-use-cases

Who Builds the Code Behind Modern Healthcare: 10 Proven Engineering Teams

Alex Natskovich — Wed, 08 Oct 2025 11:06:05 +0000

Healthcare software in 2025 operates under constant tension — strict compliance, rapid digital transformation, and legacy systems that refuse to die.
Every new regulation or integration adds another layer of complexity to already fragile infrastructures.
Below is an overview of how the sector is evolving, what challenges define it, and which vendors have demonstrated reliable technical execution in production.

The 2025 Healthcare Software Landscape

Healthcare applications have expanded far beyond record-keeping. They now handle diagnostics, analytics, IoMT telemetry, and multi-region data exchange.
From an engineering perspective, several factors dominate the architecture and delivery strategy:

Regulatory load: Continuous HIPAA, GDPR, and SOC 2 compliance at the code, infrastructure, and operations level.
Legacy modernization: Decoupling monolithic EHR systems and migrating to API-driven microservices or hybrid cloud setups.
Scalability: Supporting unpredictable demand in telemedicine and connected devices.
Interoperability: Implementing FHIR-based data models, HL7 interfaces, and standardized event streams across vendors.
Security & reliability: End-to-end encryption, fine-grained IAM, and auditable CI/CD pipelines.

Engineering teams succeeding here treat compliance and scalability as architectural principles, not post-deployment checkboxes.

Core Engineering Challenges in Healthcare Development

2.1 Compliance by Design

Embedding regulatory requirements into development workflows is essential.
Successful teams automate policy enforcement in CI/CD — scanning dependencies, validating encryption standards, and producing audit reports as part of builds.

2.2 Modernization Without Downtime

Replacing legacy EHR systems rarely allows full rebuilds. The practical approach is incremental modernization — introducing service layers, containerizing critical modules, and migrating to the cloud through zero-downtime strategies.

2.3 Interoperability & Standards

FHIR, HL7, and DICOM remain the backbone of healthcare data exchange. Engineers must balance strict schema validation with the real-world inconsistencies of legacy hospital systems.

2.4 Observability & Auditability

Every production event — from deployment to data access — must be traceable. Advanced vendors implement centralized logging, automated incident reporting, and immutable audit trails.

Evaluation Framework for Vendors

Technical performance in healthcare depends on measurable maturity rather than marketing claims.

When assessing an external engineering partner, focus on:
Documented compliance workflows (HIPAA/GDPR/SOC 2/ISO 27001).
Automated testing, validation, and release pipelines.
Proven integration with FHIR/HL7 data models.
Infrastructure as Code and reproducible environments.
24/7 monitoring and clear SLA metrics.

Leading Vendors in 2025

MEV

20 years of regulated software engineering.
Focuses on HIPAA-compliant modernization, data-intensive platforms, and IoMT integrations.
Key stack: AWS/GCP, Kubernetes, Terraform, React, Node.js.
Specialization: modernization, analytics, cloud migration.

ScienceSoft

ISO-certified enterprise vendor with 150 + healthcare projects.
Delivers EHR, analytics, and FDA-ready medical device software.
Specialization: large-scale systems with formal QA and audit documentation.

Itransition

Engineering partner for hospitals and payers running complex IT ecosystems.
Strengths include FHIR/DICOM integrations and legacy modernization.
Specialization: enterprise interoperability and sustained system support.

ELEKS

Data engineering and predictive analytics for healthcare operations.
Applies advanced ML and BI to clinical decision support.
Specialization: analytics pipelines and interoperability projects.

ITRex Group

Full-cycle vendor covering EHR, RPM, lab automation, and AI-assisted diagnostics.
Focus: reliability of distributed healthcare systems.
Specialization: multi-service clinical platforms.

GloriumTech

Supports medtech and biotech startups with compliant device software.
Specialization: embedded systems, mHealth apps, and telemedicine platforms.

Arkenea

US-focused vendor building telehealth and patient engagement platforms.
Specialization: HIPAA-compliant portals, healthcare CRM, and clinician UX.

SumatoSoft

Agile team delivering HIPAA- and FHIR-based apps.
Specialization: lightweight integrations, patient portals, and analytics dashboards.

Moon Technolabs

Global development provider with experience in scalable cross-platform healthcare apps.
Specialization: mobile and web telemedicine systems.

Innowise

IoMT and diagnostic platform expert.
Holds ISO 13485, ISO 27001, and HIPAA certifications.
Specialization: device connectivity, EHR/HIE, and remote monitoring.

Architectural Patterns Across Leaders

Across these vendors, several engineering patterns consistently appear.
Most have replaced legacy monoliths with service-oriented architectures that support modular upgrades and independent deployments. Their infrastructures are built to be cloud-agnostic, commonly using tools such as Terraform or Pulumi to ensure reproducible, portable environments.
Testing and validation are integrated directly into regulated CI/CD pipelines. Each release passes automated compliance checks and quality gates before deployment, reducing human error and improving traceability.
Observability is treated as part of architecture, not an afterthought. Centralized logging, performance metrics, and alerting systems — typically based on Prometheus or the ELK stack — provide real-time insight into production behavior.
Many have also begun adopting the latest FHIR R5 standards and event-driven data exchange models, improving interoperability between systems and enabling faster response times across healthcare networks.
Together, these practices shorten release cycles, reduce operational risk, and accelerate compliance verification — the core metrics that define engineering maturity in healthcare software.

Key Takeaways

Treat compliance as part of software design, not post-deployment QA.
Prioritize vendors with reproducible infrastructure and transparent delivery metrics.
Validate interoperability early — test data exchange during sprint cycles, not after.
Modernization should be evolutionary, guided by measurable uptime and audit readiness.
Select partners with proven experience in regulated CI/CD and post-release monitoring.