How should AI actually take actions inside software?
Not generate instructions for an action.
Not tell the user which buttons to click.
Actually execute it.
That question started with the OpenVerb Protocol and has since expanded into an ecosystem of frameworks, developer packages, applications, portable workflow files, policy infrastructure, and execution tooling.
Here’s what I’ve been building.
⸻
- The OpenVerb Protocol
At the foundation is the concept of a verb.
Applications expose capabilities using structured names:
email.send
crm.create_contact
gis.add_layer
file.move
Instead of giving an agent unrestricted application access, the AI requests a known capability.
The basic execution model is:
Intent
↓
Verb
↓
Schema
↓
Policy
↓
Executor
↓
Receipt
The AI provides intelligence.
OpenVerb provides the execution contract.
⸻
- The OpenVerb Framework
A protocol isn’t particularly useful if developers can’t implement it.
So I built the framework around it.
The developer stack includes components such as:
Runtime
Policy
SDK
CLI
Core
The Runtime handles execution.
The Policy Engine controls whether execution is permitted.
The SDK provides programmatic access.
The CLI provides developer tooling.
And Core provides shared foundations across the ecosystem.
An application can register capabilities while OpenVerb handles the infrastructure surrounding their execution.
⸻
- Policy-Controlled Execution
One of the ideas I care about most in OpenVerb is separating:
CAN EXECUTE
from:
SHOULD EXECUTE
An agent might know that email.send exists.
That doesn’t automatically mean it should be allowed to execute it.
Policy can sit directly in the execution path:
Agent
↓
Verb Request
↓
Validation
↓
Policy
↓
Execution
As agents gain more autonomy, I think this distinction becomes increasingly important.
⸻
- Receipts
Execution also needs evidence.
If an agent says:
“I updated the CRM.”
I want infrastructure capable of answering:
What changed?
Which verb executed?
What inputs were used?
Did execution succeed?
What happened afterward?
That’s why receipts are part of the OpenVerb architecture.
Request → Execute → Result → Receipt
The goal is to make AI execution more observable and auditable.
⸻
- .ov — Portable AI Workflows
Then I started thinking about another problem.
AI can generate workflows, but those workflows are frequently trapped inside the application or conversation that generated them.
So I created the .ov format.
The idea:
Prompt
↓
Generate Workflow
↓
Save .ov
↓
Inspect
↓
Execute
↓
Share
↓
Reuse
Instead of an AI workflow being temporary application state, it can become a portable artifact.
A .ov workflow can describe things such as:
name: client-onboarding
steps:
- verb: crm.create_contact
- verb: document.generate
- verb: email.send
Now the workflow is something that can potentially be versioned, inspected, shared, and executed by compatible environments.
⸻
- OpenVerb Viewer
Once .ov became a file format, another question appeared:
What opens the file?
That’s what led to OpenVerb Viewer.
I’ve been building Viewer as a cross-platform application for interacting with .ov files, including:
- workflow visualization
- graph views
- strict validation
- inspection
- offline verb simulation
One way I think about it:
If .ov is the portable workflow, Viewer is the reader.
⸻
- OpenVerb Studio
Viewer handles inspection.
Studio explores creation and execution.
The workflow I’m building toward is:
Describe workflow
↓
AI generates .ov
↓
Inspect
↓
Provide inputs
↓
Execute
↓
Output
↓
Save
That creates an interesting bridge between natural-language AI and deterministic workflow infrastructure.
AI helps create the workflow.
OpenVerb provides the structure around executing it.
⸻
- OpenVerb CRM
I’ve also been building applications on top of the execution model.
One example is OpenVerb CRM.
A request such as:
"Create a contact for Sarah Chen at Atlas Engineering."
can become:
{
"verb": "crm.create_contact",
"input": {
"first_name": "Sarah",
"last_name": "Chen",
"company": "Atlas Engineering"
}
}
That request can then move through validation, policy, execution, and receipt generation.
The CRM isn’t just another OpenVerb package.
It’s an example of what software looks like when its capabilities are designed around structured AI execution.
⸻
- OpenVerb GIS
My background is in GIS and land surveying, so I also started applying the architecture to geospatial software.
Imagine a GIS environment exposing:
gis.create_project
gis.add_layer
gis.query_features
gis.transform
gis.export
Now an AI doesn’t need arbitrary control over the entire GIS interface.
It requests defined geospatial capabilities.
Natural Language
↓
GIS Verb
↓
Schema
↓
Policy
↓
GIS Executor
↓
Receipt
That’s the idea behind OpenVerb GIS.
⸻
- The Broader Developer Ecosystem
OpenVerb has continued expanding into supporting packages and experiments.
The ecosystem now includes work around:
Runtime
Policy
SDK
CLI
Core
IDE
CRM
GIS
Pulse
Stdlib
Markdown
.ov
Viewer
Studio
And OpenVerb isn’t limited to TypeScript.
I’ve also been building the Python side of the ecosystem, including:
OpenVerb Core
Fellowship
The goal isn’t to force developers into one giant framework.
It’s to make the architecture modular.
Use the pieces you need.
Extend the parts relevant to your application.
Build new verbs.
Build new executors.
Build new tooling.
⸻
- Toward a Universal Execution Layer
The larger architecture I’m exploring looks something like this:
AI / AGENT / COPILOT
│
▼
OPENVERB
│
┌────────────┼────────────┐
▼ ▼ ▼
CRM GIS EMAIL
│ │ │
VERBS VERBS VERBS
│ │ │
└────────────┼────────────┘
▼
POLICY + EXECUTION
│
▼
RECEIPT
Models can change.
Agents can change.
Applications can change.
The execution contract remains understandable.
That’s why I’ve increasingly thought about OpenVerb as a potential universal runner for AI actions.
Applications provide capabilities.
Models provide intelligence.
OpenVerb sits between intelligence and execution.
⸻
The Ecosystem Is Still Growing
What began as the OpenVerb Protocol has expanded into:
Protocol → Framework → Runtime → Policy → SDK → CLI → .ov → Viewer → Studio → CRM → GIS → IDE → Pulse → Stdlib → Python → Fellowship
But all of those projects revolve around the same underlying idea:
AI needs an execution layer.
As AI systems move from generating answers toward performing real work, I think we’ll need infrastructure for defining capabilities, validating requests, enforcing policies, executing actions, and proving what happened.
That’s what I’m building with OpenVerb.
⚡ OpenVerb
https://openverb.dev
📦 NPM
https://www.npmjs.com/package/openverb
If you’re building agents, copilots, automation systems, developer tools, or AI infrastructure, I’d love to hear what you think — and especially what you’d build on top of an open execution layer.
Top comments (0)