DEV Community

Nayantara P S
Nayantara P S

Posted on

AI Workflows Require Context: Designing AI That Understands More Than What You Ask

AI is very good at working with individual messages and inputs.

If you hand a model a customer message it can classify it. If you give it equipment data it can recognize unusual patterns. When you give it a dataset it can output SQL and analysis.

So, what makes for a harder engineering task? What makes applications require more than an isolated input message?

The Input Message Has More

Take a use case around equipment monitoring.

A sensor provides this reading:


temperature = 82°C

Enter fullscreen mode Exit fullscreen mode

This message could be normal, depending on the circumstances.

Maybe the machine is running on a higher load. Perhaps it is a warmer ambient temperature. Possibly the equipment was just serviced.

For a useful application, the model needs additional information.

Perhaps such as this:


asset_id

timestamp

operating_mode

load

history

maintenance

temperature

Enter fullscreen mode Exit fullscreen mode

And then the model can consider the current reading and determine if anything is wrong.

Add a Context Layer

One approach to this problem could be such an architecture:


Data Sources

↓

Data Processing

↓

Context / Metadata

↓

AI + Rules + Analytics

↓

Recommendation

↓

Human Review

↓

Business Workflow

Enter fullscreen mode Exit fullscreen mode

The context layer can take many forms, depending on the application. It could be a database, feature store, metadata management layer, semantic layer, knowledge base, or even application-specific data model.

The key thing is that the AI system can have richer context and data than was given directly.

The important detail is that the AI gets relevant information, rather than the input on its own.

The Context Has Traceability

If someone in operations asks "why did the AI say what it said?"

developers may have to explain what data the AI had available and why.

They may need to explain what particular model version made the prediction.

They may also have to explain what rules, if any, the AI used.

Or if and how a human reviewed the recommendation.

Was the AI recommendation followed?

What was the outcome? Did the equipment fail?

These are all reasons recordkeeping and observability are important.

A record of a single AI-driven workflow might look like this:


request_id

asset_id

timestamp

model_version

input_reference

context_reference

prediction

confidence

review_status

final_action

Enter fullscreen mode Exit fullscreen mode

There is also no need to retain training data or raw inputs unless it becomes relevant for debugging or governance. By using references and carefully structured metadata, it can often be possible to retain just enough information for these purposes without having to store everything.

It Is Not Always More Data

It can be tempting - especially with the hype around large language models - to assume that passing more data to the model will always improve results.

A bigger version of the same model, potentially. A larger dataset. Even adding more fields and context.

This is not always the case, and has significant downsides for both cost and performance.

There is also the issue of what to do with the data.

The better question when designing an AI-driven application is likely to be: what does the person who knows how to handle this situation need to know?

What information would a technician or engineer need to know in order to make a decision?

This can often be a good starting point when designing an application's input for the AI.

Predictions Have a Purpose

Unless there is a process for the AI's output, it may not have much value. For example:


Sensor Data

↓

Anomaly Detection

↓

Risk Assessment

↓

Maintenance Recommendation

↓

Technician Review

↓

Work Order

Enter fullscreen mode Exit fullscreen mode

The AI is only one part of the overall application. What the rest of the application does is what makes the overall system valuable.

This is also important for the industrial space in particular, because it means that AI outputs can feed directly into other processes. From field service, to logistics, to inventory management and equipment upgrades.

AI Applications Need Feedback

The overall application should also be able to provide feedback to the AI.

Was the recommendation followed?

Did the technician report a different result?

Did the equipment actually fail, and if so, how?

Was the AI recommendation correct, and if not, why?

The more information can be provided in this feedback, the more valuable it tends to be.

It also enables a feedback loop.

The AI makes a prediction. Someone reviews it. An action is taken. The results are observed. The model learns and updates.

This loop is abbreviated into this:

Predict → Review → Act → Observe → Learn → Improve

Aperture Venture Studio focuses on AI and IoT venture opportunities that involve real-world physical operations. For developers considering the space, a similar point applies - AI applications require appropriate context and traceability, but also fit into overall system workflows and provide feedback for further training.

Top comments (0)