Why We Built FieldOps AI as a Read-Only Assistant

AI can retrieve information.

It can connect related records.

It can identify patterns.

It can help explain what the monitoring data contains.

But should it be allowed to change the monitoring data itself?

When we were designing FieldOps AI, this was an important question.

We deliberately chose to build the assistant as a read-only assistant.

That means FieldOps AI can work with operational information, retrieve relevant records and help users reason about what the data shows.

But it does not independently edit visits, findings or corrective actions.

That distinction is intentional.

AI does not need to control the system to be useful

There is a common assumption that an AI system becomes more powerful when it can take actions.

An AI agent might be given permission to create records, update information, send messages or trigger workflows.

There are situations where that can be useful.

But M&E has a particular characteristic that makes the distinction important:

Monitoring data is evidence.

A monitoring visit represents something that happened.

A finding represents an observation recorded during that visit.

A corrective action represents a response to that observation.

Changing those records changes the organization's operational history.

That is different from asking AI to summarize or investigate the information.

Understanding is different from changing

Consider a simple question:

Which sites have recurring findings?

The assistant can retrieve visits, examine findings and help identify patterns.

Nothing needs to be changed.

Now consider:

Which corrective actions are still open?

Again, the assistant can retrieve the relevant information and present it to the user.

Still no change is required.

But consider a different request:

Close all the corrective actions that appear to be resolved.

Now the assistant would be making an operational decision and modifying records.

That is a fundamentally different level of responsibility.

The system would need to determine what "resolved" means, decide whether the available evidence is sufficient and then alter the organization's records.

We chose not to give the FieldOps assistant that authority.

The monitoring system remains the source of record

FieldOps has a clear separation between the operational system and the AI assistant.

The operational system stores the organization's records.

The AI assistant works with those records to help users understand and investigate them.

This means the AI is not becoming a second system of record.

A useful way to think about it is:

FieldOps stores the evidence.

FieldOps AI helps users explore the evidence.

The user remains responsible for operational decisions.

That separation is deliberate.

Consider a corrective action

Suppose a monitoring visit produces this finding:

Stock documentation was incomplete.

A corrective action is created to address the issue.

Later, an AI assistant is asked:

What corrective actions are still open for this site?

The assistant can retrieve the action and report its current status.

The user might then ask:

What findings led to these actions?

The assistant can trace the action back to the associated findings and visits.

The user might then decide that an action has actually been completed.

That decision can happen through the normal FieldOps workflow.

The AI does not need to make that decision itself.

Why this matters for M&E

M&E records are not simply pieces of text.

They can form part of an organization's accountability trail.

A monitoring visit may be reviewed.

A finding may be discussed with program teams.

A corrective action may be assigned to a responsible person.

An action may eventually be verified and closed.

Allowing an AI system to silently modify any of these records could make it difficult to distinguish between what was originally observed and what the AI later changed.

Keeping the assistant read-only creates a clearer boundary.

The AI can help interpret the record without becoming an unreviewed editor of the record.

The human remains in the loop

Read-only does not mean AI is passive.

Quite the opposite.

The assistant can still perform useful work.

It can retrieve information.

It can compare records.

It can identify recurring findings.

It can trace findings to corrective actions.

It can examine historical monitoring information.

It can answer questions about sites and visits.

It can help users investigate operational patterns.

But when the investigation reaches a point where a decision or change is required, the human remains involved.

For example:

Which corrective actions are still open?

The AI can answer.

The user then decides what should happen.

That might mean reviewing an action, updating its status, assigning follow-up or discussing the issue with the responsible team.

The AI does not have to make that decision for the system to benefit from AI.

Read-only also reduces the consequences of an incorrect answer

AI systems can make mistakes.

A model may misunderstand a question.

It may interpret two findings as related when they are not.

It may miss an important piece of context.

It may retrieve information that requires further verification.

When the assistant is read-only, an incorrect interpretation does not automatically become an incorrect database change.

The user can inspect the answer and decide what to do next.

This creates an additional layer of human review between AI reasoning and operational change.

The difference between analysis and action

This distinction is useful when thinking about AI in operational systems.

There are broadly two types of AI interaction.

Analysis

The AI helps answer questions such as:

• What happened?
• Where did it happen?
• Which findings are recurring?
• Which actions are still open?
• What changed across recent visits?
• Which sites have multiple unresolved findings?

These questions involve understanding existing information.

Action

The AI begins doing things such as:

• changing a finding;
• closing an action;
• creating a corrective action;
• changing a visit status;
• assigning an action;
• sending a notification;
• modifying organizational records.

These operations change the state of the system.

They deserve a different level of control.

FieldOps AI currently focuses on the first category.

This is why the assistant is not an autonomous agent

There is an important difference between an assistant and an autonomous agent.

An assistant helps the user.

An autonomous agent may be given authority to pursue an objective and take actions on the user's behalf.

For FieldOps, we chose the assistant model.

The user asks a question.

The assistant retrieves relevant information.

The assistant reasons over that information.

The assistant provides an answer.

The user remains responsible for deciding what happens next.

This is particularly appropriate for an environment where monitoring information can feed into management decisions, program follow-up and accountability processes.

The assistant can still use tools

Read-only does not mean the AI has no access to tools.

It means the tools available to it are controlled.

For example, FieldOps AI can use tools to retrieve relevant operational information.

The assistant can ask the application for information about sites, visits, findings and other supported records.

The application determines what information can be returned.

The assistant then reasons over that information.

This creates a useful separation:

AI reasoning does not equal database authority.

The assistant can have enough access to answer useful questions without having permission to rewrite the underlying system.

Why not simply let the AI update records?

At first glance, giving AI write access might seem convenient.

Imagine asking:

Close all corrective actions that look completed.

It sounds efficient.

But the phrase "look completed" contains a judgment.

How does the AI determine that an action is actually complete?

What evidence is required?

Was the evidence recorded in FieldOps?

Does completion require verification?

Who is authorized to close the action?

What happens if the AI misunderstands the finding?

What happens if two related actions have different statuses?

These are not simply language problems.

They are operational and governance questions.

The fact that an AI can technically perform an action does not necessarily mean that it should perform that action autonomously.

Monitoring data needs provenance

Another reason for the read-only approach is provenance.

M&E teams often need to know where an observation came from.

A finding should be associated with a visit.

A visit should be associated with a site.

A corrective action should be associated with the finding that led to it.

When an AI is analyzing these records, the original information remains intact.

This makes it easier for a user to distinguish:

What the system recorded

from

What the AI inferred from those records.

That distinction is important.

An AI-generated interpretation should not silently become indistinguishable from the underlying monitoring evidence.

AI-generated insight is not the same as source data

Suppose FieldOps AI tells a user:

Three sites appear to have recurring stock documentation findings.

That is an AI-generated interpretation of the monitoring records.

The underlying records remain the evidence.

The user should be able to investigate the visits and findings that produced the observation.

The AI is helping connect the information.

It is not replacing the information.

This distinction becomes increasingly important as AI is used for operational analysis.

Read-only does not mean "less capable"

There can be a tendency to think that an AI assistant is limited if it cannot take actions.

But consider how much useful analysis can happen without modifying a single record.

A user can ask:

Which sites have recurring findings?

Then:

Which findings are most common at those sites?

Then:

Which of those findings have corrective actions?

Then:

Which actions are still open?

Then:

Which sites have had similar issues during multiple visits?

That is a substantial amount of operational investigation.

None of it requires the AI to change the database.

The value comes from the assistant's ability to retrieve and reason across connected information.

The human can decide when an action is appropriate

Imagine the AI identifies a recurring issue.

The user reviews the relevant monitoring records.

The user decides that additional follow-up is required.

The user creates or updates the corrective action through the normal application workflow.

This creates a useful division of responsibility.

The AI helps with discovery and analysis.

The application manages the operational workflow.

The human makes the decision.

Each layer does what it is designed to do.

This approach also makes the system easier to reason about

There is a practical engineering benefit to keeping the initial assistant read-only.

The behavior is easier to understand.

The assistant receives a question.

It retrieves information.

It reasons over the information.

It produces an answer.

The underlying records remain unchanged.

That makes it easier to test the assistant's responses without simultaneously worrying about unintended operational changes.

For an AI feature being introduced into a monitoring system, that separation is valuable.

It creates a safer starting point for AI adoption

Organizations do not have to begin their AI journey by handing an AI system authority over operational workflows.

They can start by allowing teams to ask questions of the data they already have.

They can observe how useful the answers are.

They can identify where the assistant performs well.

They can identify where the data is insufficient.

They can determine which workflows might eventually benefit from additional automation.

This provides a more controlled path toward increasingly sophisticated AI capabilities.

The goal is not to keep AI away from operations

The goal is to put AI in the right place.

Operational systems need reliable records.

M&E teams need to investigate those records.

AI can help bridge the gap between the two.

That does not require AI to become the owner of the operational workflow.

In fact, keeping the boundaries clear can make the relationship more useful.

The monitoring system remains authoritative.

The AI remains an intelligence layer.

The human remains responsible for decisions.

What this means for FieldOps AI

The FieldOps AI approach can be summarized simply:

Read the operational data.

Understand the context.

Reason across related records.

Help the user investigate.

Do not silently change the source records.

This is why we chose to build FieldOps AI as a read-only assistant.

The objective is not to create an AI that takes control of an M&E system.

The objective is to make the information already captured in that system easier to understand and use.

That distinction matters.

Because in monitoring and evaluation, the most important question is not simply what AI can do.

It is also where AI should sit within the workflow.

For FieldOps, that place is currently between the organization's operational data and the people who need to understand it.

The system captures the evidence.

The AI helps explore it.

The human decides what to do with it.

Capture once. Use everywhere.