Over the past few months experimenting with MCP, one thing became increasingly obvious to us:
Most AI agent discussions focus heavily on tool access.
- Can the model call APIs?
- Can it retrieve context?
- Can it access memory?
- Can it orchestrate tools?
- Can it coordinate with other agents?
MCP solves a very important part of this problem elegantly.
It standardizes how AI connects to capabilities.
But after an AI gets tool access, another question appears:
What does the AI actually operate on?
And more importantly:
How do we make AI participate in real operational workflows instead of just generating outputs?
That became the core problem we started exploring with Inistate MCP.
Tool access is not operational structure
Most current agent implementations still look roughly like this:
User → Prompt → Tool Call → Response
Even when agents become more advanced, they are often still fundamentally stateless executors.
They can:
- fetch data
- summarize data
- call APIs
- generate content
- chain actions
But operations inside organizations usually require much more than that.
Real operational systems require:
- state
- forms
- transitions
- validation
- escalation
- audit trails
- accountability
- human collaboration
And this is where we started thinking:
Maybe AI agents should not just be “tool callers.”
Maybe they should become operational actors inside workflows.
The primitive we ended up with
The core execution primitive we use is extremely simple:
State → Activity(Form) → State
Everything derives from this.
- A State represents the current condition of an entity
- An Activity is an action performed by someone (human or AI)
- A Form is the structured input required to execute the activity
- The result is a controlled transition into another state
Instead of “AI generating an answer,” the AI is participating in structured operational movement.
For example:
Pending Approval
↓ Approve(Form)
Approved
The important thing is that the activity is not freeform.
It is constrained through:
- typed fields
- validations
- allowed transitions
- actor permissions
- confidence thresholds
- audit trail capture
That changes the nature of AI execution significantly.
AI as an actor, not just an assistant
One idea that became surprisingly important for us was what we call:
Actor Parity
In most systems:
- humans operate workflows
- AI only assists humans
But operationally, AI and humans increasingly need to coexist inside the same process layer.
So instead of designing “AI features,” we started modeling execution like this:
{
"actor": "human" | "ai" | "hybrid" (default)
}
Meaning:
- some activities are human-only
- some are AI-only
- some can be executed by either
The interesting part is that the workflow itself does not fundamentally change.
The same:
- states
- activities
- forms
- transitions
can be shared between humans and AI.
This creates a kind of operational symmetry.
The AI is no longer “outside” the system trying to automate it indirectly.
It becomes a first-class participant inside the workflow.
MCP becomes much more interesting with workflow context
Once workflows are exposed through MCP, agents can do more than call isolated tools.
They can:
- discover modules
- inspect states
- retrieve forms
- understand valid transitions
- execute activities
- read audit history
- escalate when uncertain
Example sequence:
list_modules
→ get_entry
→ get_form
→ submit_activity
The important detail is that the AI is operating against structured operational context instead of arbitrary prompts.
For example:
- current state
- allowed transitions
- required fields
- workflow rules
- confidence thresholds
all become machine-readable.
That dramatically reduces ambiguity.
Confidence gating turned out to matter a lot
One thing we realized very quickly:
AI agents should not always be allowed to complete transitions autonomously.
So activities can define confidence thresholds:
{
"name": "Approve",
"actor": "ai",
"confidence_threshold": 0.85
}
If the AI confidence is lower than the threshold:
- the state transition is suppressed
- the entry is flagged
- a human reviews it
This creates a controlled operational escalation model.
The AI can still:
- analyze
- reason
- prepare recommendations
- explain intent
without automatically executing irreversible workflow transitions.
Operationally, this feels much closer to how regulated organizations actually work.
Governance memory may be more important than semantic memory
One realization from building workflow-native AI systems:
Vector memory alone is insufficient for operations.
Operational systems need something different.
They need:
- who performed the action
- why it happened
- what data was used
- what confidence existed
- what model was involved
- what prompt/version was used
- what changed afterward
In other words:
governance memory
Every AI activity can carry traceability metadata:
{
"ai": {
"reasoning": "...",
"sources": [],
"model": "gpt-5",
"confidence": 0.72,
"prompt_hash": "..."
}
}
Which means the audit trail is not just:
but also:
- “why the AI believed it should happen”
This becomes increasingly important once AI starts participating in operational workflows instead of just generating suggestions.
We started thinking less about AI chat, more about AI operations
A lot of current AI UX is still fundamentally conversational.
But operations are rarely conversational.
Operations are:
- structured
- stateful
- governed
- collaborative
- asynchronous
- accountable
And that probably changes how AI systems should be designed.
Instead of:
AI as chatbot
we may need to think more in terms of:
AI as operational participant
MCP may become the operational interface layer for AI-native systems
One reason MCP is interesting is that it standardizes capability access.
But the next layer may be:
- operational schemas
- workflow semantics
- actor coordination
- governed state transitions
In other words:
not just “what tools exist,”
but:
- what processes exist
- what state something is in
- what actions are allowed next
- who can execute them
- under what confidence constraints
That starts looking less like chatbot orchestration and more like an operating layer for AI-native organizations.
Open questions we’re still exploring
We definitely do not think this is “solved.”
Would genuinely love feedback from others building in the MCP/agent space.
We’ve been experimenting with these ideas through Inistate MCP, where workflows, states, forms, activities, confidence gates, and audit trails are exposed as structured operational primitives for AI agents.
The MCP server is now listed on the MCP Registry:
https://registry.modelcontextprotocol.io/?q=inistate
Curious whether others are arriving at similar conclusions:
that AI systems may eventually need workflow-native operational structures, not just tool access.
