DEV Community: Sergii Miasoiedov

https://medium.com/@s.myasoedov81/ai-executes-no-one-signed-d2f143ef6aee

Sergii Miasoiedov — Thu, 19 Mar 2026 12:05:17 +0000

medium.com

Decision Stack

Sergii Miasoiedov — Wed, 18 Mar 2026 06:35:52 +0000

✖ ✖ ✖ ✖ ✖ ✖ ✖

topic: decision_stack

Lately I’ve been following Cristiano Messina’s “Decision Stack” series.

A very interesting and professional perspective
on how modern systems should be designed.

The model is simple but powerful:

signals → context → objectives → constraints → execution → feedback

Where:

signals detect change

context defines meaning

objectives define what matters

constraints define boundaries

execution performs actions

feedback drives learning

✖

A question to practitioners:

Which of these layers
are already explicitly implemented
in your systems?

And in what form?

Are they:

centralized

scattered

implicit

formalized

✖

Curious how others structure this today.

✖ ✖ ✖ ✖ ✖ ✖ ✖

Decision Stack

Sergii Miasoiedov — Wed, 18 Mar 2026 06:15:05 +0000

✖ ✖ ✖ ✖ ✖ ✖ ✖

topic: decision_stack

Lately I’ve been following Cristiano Messina’s “Decision Stack” series.

A very interesting and professional perspective
on how modern systems should be designed.

The model is simple but powerful:

signals → context → objectives → constraints → execution → feedback

Where:

signals detect change

context defines meaning

objectives define what matters

constraints define boundaries

execution performs actions

feedback drives learning

✖

A question to practitioners:

Which of these layers
are already explicitly implemented
in your systems?

And in what form?

Are they:

centralized

scattered

implicit

formalized

✖

Curious how others structure this today.

✖ ✖ ✖ ✖ ✖ ✖ ✖

From Prompts to Contracts: Why I Built the MOVA Contract Agent

Sergii Miasoiedov — Mon, 16 Mar 2026 17:49:36 +0000

The Problem

Over the past year, AI agents have become incredibly powerful.

Tools like large language models, coding assistants, and browser agents can already perform complex tasks.

But there is still a fundamental problem.

Most AI interactions today are based on prompts.

A user writes instructions in natural language and hopes the model interprets them correctly.

This works for experimentation, but it becomes fragile when applied to real business processes.

A business task is not just a conversation.

It has:

rules
policies
verification
responsibility for the result

Without structure, AI execution becomes unpredictable.

That question led me to explore a different approach.

What if business tasks were not executed through prompts, but through contracts?

The Idea

Instead of asking an AI agent to “solve a problem,” the system should first transform the request into a structured contract.

A contract defines:

what the user intends to achieve
which policies apply
what actions are allowed
how success will be verified

Only after the contract is created does the agent execute the task.

This changes the role of AI.

The agent is no longer improvising a solution.

It is executing a defined agreement.

The Architecture

The architecture of the system reflects this idea.

A user request first enters the system as a simple description of a problem.

The system then performs three steps:

Intent Detection – understanding what the user is trying to accomplish.
Contract Creation – generating a structured contract that defines the task and the execution rules.
Execution – an agent performs the task according to the contract and produces a verifiable result.

This architecture separates intention, policy, and execution into clearly defined layers.

It allows AI-driven processes to become traceable, auditable, and repeatable.

In the next part of the demo, I show how this architecture works in practice.

The Demo Scenario

For the hackathon demonstration I chose a simple but realistic use case:

customer support tickets.

A user sends a ticket describing a problem and attaches a screenshot.

The system:

analyzes the request
identifies the problem category
selects the corresponding solution contract
executes the resolution workflow

If the issue cannot be resolved automatically, the system escalates the ticket to a human operator.

This shows how everyday business tasks can be handled through contract-based AI execution.

What I Learned

Building this project reinforced an important idea.

AI systems become far more reliable when they operate inside clear operational structures.

Instead of asking AI to decide everything dynamically, we can:

define contracts
apply policies
verify outcomes

This approach turns AI from an unpredictable assistant into a controlled execution system.

Conclusion

The goal of this project is not to create another chatbot.

It is to demonstrate a different way of thinking about AI-driven workflows.

By introducing contracts as the core execution unit, business processes can become safer, more transparent, and easier to automate.

This project is a small step toward that direction.

From Prompts to Contracts: What Is Required for Businesses to Reliably Adopt Agentic AI

Sergii Miasoiedov — Sun, 15 Mar 2026 18:42:23 +0000

The Question

What is required for businesses to confidently adopt agentic AI in their processes and use it to solve real business tasks?

At first glance, the answer seems obvious:
you need a strong model, access to data, and good automation.

But when the conversation moves from demonstrations to real deployment, it quickly becomes clear that this is not enough.

Businesses care not only about the capabilities of a system, but about its properties as an operational tool.

They need to understand:
• what exactly the system is doing;
• what result counts as successful;
• why a particular decision was made;
• whether the result can be reproduced;
• and how much it costs to execute a task.

The last point is particularly important.

For a business, it is not enough to know how many tokens a model consumes on average.
What matters is the cost of a unit of useful work:
• how much it costs to resolve a support ticket;
• how much it costs to validate a scenario;
• how much it costs to execute a task.

Without this level of measurement, agentic AI is difficult to integrate into real operational economics.

⸻

The Current Architecture and Its Limitations

Today, most AI agents are built around the same basic scheme:

prompt → model → result

When this proves insufficient, developers start adding additional layers around the model:
• workflows
• orchestrators
• observability
• logs
• traces
• policies
• external checks

But the underlying logic remains the same:
the system receives a textual description of a task, and the model attempts to interpret and execute it.

This approach has several fundamental limitations.

2.1 Prompts Are Not a Formal Unit of Control

A prompt is simply a description of a task in natural language.

While convenient for experimentation, it is poorly suited for managing complex systems because:
• it cannot be validated before execution;
• it is difficult to formally analyze;
• it is hard to reproduce without drift;
• it provides weak boundaries for allowed actions.

2.2 Workflows Do Not Fully Solve the Problem

Many systems attempt to compensate for this by introducing workflow architectures, where the model becomes just one step in a predefined pipeline.

But in this case the AI acts merely as a “smart function” inside a rigid process.

This limits its usefulness in situations where the system needs to:
• analyze complex situations,
• compare alternatives,
• choose a path of action,
• operate under incomplete information.

2.3 Observability Shows Activity but Not Meaning

Even when systems collect detailed observability signals, we often still cannot interpret them with confidence.

Why?

Because observability shows:
• what happened,
• which calls were made,
• which steps were executed.

But it cannot answer the most important question:

Was this supposed to happen within the context of the task?

To answer that question, the system needs two additional elements:
• a clearly defined intent,
• and a formal execution contract.

⸻

What Businesses Currently Lack

Strictly speaking, businesses do not primarily need another model or another pipeline.

What they lack is an architecture where agentic AI becomes:
• understandable
• controllable
• verifiable
• measurable
• reproducible

In other words, businesses need more than a model output.

They need a system where it is possible to determine in advance:
• what outcome is expected,
• what the agent is allowed to do,
• how the result will be verified,
• how the execution will be recorded,
• and how the cost of the task will be calculated.

Without these properties, deployment remains an experiment rather than a production system.

⸻

The Proposed Solution

My answer to this problem is a shift toward a different architecture.

Instead of:

prompt → model → result

I propose the following structure:

intent → contract → validation → execution → verification → episode

In this architecture, the key element is not the prompt but the intent.

4.1 Intent

Intent defines:
• what task we are actually trying to solve,
• what result is considered successful,
• what boundaries are acceptable,
• what constitutes completion.

4.2 Contract

Once the intent is defined, the task can be described as a contract.

A contract is a structured description of the allowed solution space.

It defines:
• inputs,
• expected outputs,
• allowed actions,
• constraints,
• execution rules,
• and success criteria.

4.3 Validation

Because the contract is formally described, it can be checked before execution begins.

This becomes the first safety layer.

When contracts are defined using JSON Schema, they can be validated structurally — including types, constraints, and required fields — before the agent performs any action.

4.4 Execution

After validation, the contract is executed with the assistance of the model.

However, the model is no longer operating in an open-ended space.
It operates within formally defined boundaries.

4.5 Verification

After execution, the result must be verified.

The system checks whether:
• the contract was actually fulfilled,
• the result matches expectations,
• the execution remained within allowed boundaries.

4.6 Episode

Finally, the execution is recorded as an episode.

An episode captures:
• the input signals,
• the selected contract,
• the execution process,
• and the resulting outcome.

The cycle can then repeat.

⸻

The Execution Cycle

The overall architecture looks like this:

intent
↓
contract
↓
validation
↓
execution
↓
verification
↓
episode
↓
next cycle

This is an important shift.

In this architecture, AI is no longer a component that simply produces answers from text.
Instead, it becomes part of a closed and controlled execution loop.

The system can now:
• formalize a task,
• validate it,
• execute it,
• verify the result,
• and record the experience.

⸻

Advantages of This Approach

Control

Contracts define the allowed boundaries of agent behavior.
The system no longer operates purely through open-ended reasoning.

Verifiability

Two layers of checks appear:
• validation before execution
• verification after execution

Reproducibility

If tasks are defined through contracts and results are recorded as episodes, processes can be reproduced and compared.

Meaningful Observability

Observability becomes interpretable because it now has context:
• intent
• contract
• expected outcome

Execution Economics

Contracts make tasks measurable.

Instead of counting abstract token usage, systems can measure:
• the cost of executing a contract,
• the cost per unit of work,
• the cost of recurring episodes,
• the cost difference between reasoning and deterministic execution.

This allows businesses to reason about the real economic cost of tasks.

A Path Toward Deterministic Execution

As episodes accumulate, recurring cases can be recognized and handled without repeated reasoning.

Over time, part of the workload can move into a deterministic execution layer.

⸻

What Has Already Been Developed

Over the past year and a half, I have developed a language for formally describing processes.

This language allows different types of system entities and workflows to be described, including:
• data structures
• specifications
• pipelines
• workflows
• agent cycles
• contracts
• execution episodes

Contracts are only one application of this language.

The system includes multiple representational layers, such as:
• schemas
• envelopes
• global context definitions
• episode recording
• semantic relationships between layers.

In other words, this is not a one-off format for a specific use case.

It is a broader system that allows processes to be:
• described
• validated
• executed
• observed
• analyzed.

An execution engine for contracts and a mechanism for recording episodes have already been implemented, meaning the architecture is not only theoretical but supported by working tools.

⸻

Why This Makes Real Adoption Possible

Businesses do not adopt AI simply because models are intelligent.

They adopt AI when it can be integrated into systems of responsibility, control, measurement, and repeatability.

Contract-based architectures make this possible.

They allow organizations to:
• formalize tasks,
• validate them before execution,
• execute them in a controlled way,
• verify results,
• record episodes,
• and improve future cycles.

This is the transition from experimental model usage to real deployment of agentic AI in business processes.

⸻

Conclusion

If businesses want to reliably deploy agentic AI, prompts, workflows, and observability alone are not enough.

What is needed is an architecture built around:
• intent,
• contracts,
• validation,
• execution,
• verification,
• episodes,
• and measurable task cost.

Moving from prompts to contracts is not just an interface change.

It is a shift toward an architecture where agentic AI becomes:
• controllable,
• verifiable,
• reproducible,
• and economically measurable.

These are precisely the properties required when AI systems move from experimentation into real operational environments.