IntentOS
Reliable AI Delegation
IntentOS makes AI delegation controlled, portable, and verifiable.
IntentOS is an open-source, vendor-neutral control and trust layer between human intent and AI execution. It turns rough goals into reviewable delegation contracts: what should be done, relevant context, constraints, risk, approval boundaries, an appropriate execution target/process, and evidence needed to establish completion. The chosen AI tool or agent performs the work.
Software engineering and DevOps are the initial product wedge and current domain-policy support. The long-term vision serves professionals across domains without requiring expertise in prompt engineering, model routing, MCP, or agent internals. Wider domain support requires evidence and separately scoped work.
Intent
→ Normalize / clarify
→ Task + risk
→ Relevant project context
→ Engineering / DevOps policy
→ AI / model route
→ Optimized execution prompt / portable Skill
→ Verification contract
→ Evaluation + versioned run record
→ Learning
Why IntentOS?
A delegation needs a clear goal, relevant context, constraints, risk awareness, and a way to verify the result.
For software engineering and DevOps, that includes engineering expectations, capability/effort guidance, and evidence from actual outcomes. IntentOS makes these concerns explicit in the existing Prepare → Review → Copy workflow and portable preparation artifacts.
Trust comes from explicit interpretation, traceable context, visible assumptions, constraints, consequential human approval, verification criteria, and outcome evidence. IntentOS does not guarantee AI correctness; its preparation guidance does not enforce an agent's permissions or certify completed work.
What makes it different
- Intent contracts — preserve and clarify the goal, scope, constraints, and success criteria in a reviewable execution prompt or portable Skill.
- Context-aware engineering — KISS/YAGNI by default; SOLID, DRY, Clean Code, security, and DevOps guidance only when the task actually benefits from them.
- Risk-aware delegation — production, security, schema, destructive, and persistent changes get stronger approval boundaries.
- Minimal project context — rank, deduplicate, and budget repository context instead of dumping the whole repo into the agent.
- Portable agent context — compile reusable
SKILL.mdartifacts instead of repeating the same instructions in every conversation. - Agent workspace hygiene — detect missing, stale, duplicate, or bloated agent-facing files and propose safe updates.
- Future-proof model routing — route by capability, effort, availability, surface compatibility, and relative cost without hardcoding today's model names into the core.
- Evidence over intuition — regression assertions, A/B ranking, token/latency/retry metrics, versioned privacy-minimal run records, and repeated-failure learning proposals.
- Ease of use by design — common workflows should not require prompt-engineering, model-routing, MCP, or internal architecture knowledge.
- Vendor-neutral core — provider-specific behavior lives behind profiles/adapters.
How people should use IntentOS
IntentOS is designed as one shared core with multiple access surfaces so different users can work in the environment that fits them.
IntentOS Core
│
┌───────────────────┼───────────────────┐
│ │ │
Simple UI VS Code UX CLI / API
│ │ │
└───────────────────┼───────────────────┘
│
MCP
│
Compatible AI agents/tools
Current surfaces:
- CLI — portable use from the terminal and scripts.
- Python API — programmatic access for integrations and automation.
- MCP adapter — optional local stdio connection exposing one bounded
prepare_tasktool. - VS Code extension (minimum slice) — one
IntentOS: Prepare Taskcommand with temporary review and Copy Prepared Task. - Agent Skills — portable, reusable
SKILL.mdguidance.
Deferred candidate surface:
- Simple UI — an outcome-first experience for users who should not need CLI or prompt-engineering knowledge. Phase 7C evidence did not justify starting it; any future work remains evidence-gated.
Broader VS Code handoff/execution features remain gated by editor dogfooding rather than being assumed up front.
Advanced controls should use progressive disclosure: everyday users see simple outcome-first actions, while experts can inspect and control context, risk, policy, routing, cost, approvals, and verification.
See docs/UX.md for the product usage and UX contract.
Quick start
Requires Python 3.11+.
Stable release installation
IntentOS 1.0.0 is the current stable release. Install it without cloning the repository:
python -m pip install intentos-engineering
intentos --help
intentos optimize "Refactor the parser" --target codex
The Python distribution is named intentos-engineering; its import package and CLI remain intentos. A clean public installation of version 1.0.0 was verified.
Development checkout
git clone https://github.com/milad-seify/IntentOS.git
cd IntentOS
python -m pip install -e .
Optimize a request for Codex:
intentos optimize "Refactor the auth module without changing behavior" \
--target codex \
--constraint "No new dependencies" \
--success "Relevant tests pass"
If the target is named in the request, the CLI can detect it:
intentos optimize "Codex: refactor the parser without changing behavior"
Use project context:
intentos optimize "Refactor the parser" \
--target codex \
--context-file AGENTS.md \
--context-file docs/ARCHITECTURE.md
Compile the same engineering contract into a portable Agent Skill without writing files:
intentos skill "Refactor the parser" \
--target codex \
--name parser-refactor
Machine-readable output:
intentos optimize "Review this architecture" --target claude --json
JSON mode returns the versioned machine contract documented in docs/PUBLIC_CONTRACT.md. Schema versioning is independent from the Python package version. The v1 contract is frozen; package version 1.0.0 is the current stable release.
Plan agent workspace maintenance without writing files:
intentos workspace \
--phase "Phase 7B — minimum VS Code UX" \
--document AGENTS.md \
--document docs/STATUS.md
workspace and skill are proposal-first: they emit reviewable artifacts; they do not silently mutate or install anything in your repository.
You can also run the CLI as a module:
python -m intentos optimize "Fix the failing parser test" --target codex
MCP adapter
MCP support is optional so the standard-library core remains lightweight.
Install the MCP extra without cloning:
python -m pip install "intentos-engineering[mcp]"
For development, contributors can install the extra from a repository checkout with python -m pip install -e ".[mcp]".
A compatible local MCP host can launch:
intentos-mcp
The server uses stdio and exposes exactly one tool: prepare_task.
prepare_task accepts the user request, optional target tool, constraints, success criteria, output format/audience, and bounded caller-supplied project context. Project context entries contain only path labels and content; IntentOS does not read those paths from the filesystem. The first slice accepts at most 32 context documents and 6000 characters total.
The MCP result uses the same versioned machine contract as the CLI: ready/clarification status, prepared prompt, task/risk decision, engineering and approval boundaries, routing, context diagnostics, and verification criteria.
MCP preparation does not execute the task, authorize a risky action, mutate the repository, expose workspace/Skill/run-record operations, or turn IntentOS into a general MCP runtime.
VS Code extension
Install the IntentOS extension from the Visual Studio Marketplace. First install the local CLI:
python -m pip install intentos-engineering
Then install the extension from the Marketplace and use this flow:
Request
→ IntentOS preparation
→ Review
→ Copy Prepared Task
→ hand off to Codex / ChatGPT / Claude / Gemini / Cursor / another AI tool
The extension uses the editable package installation only for local development. IntentOS 1.0.0 is also available as the stable public package.
The first editor slice lives in integrations/vscode and intentionally has no npm runtime dependencies or build pipeline.
Current flow:
- make sure the
intentosCLI is available to the VS Code extension host - select request text in an editor, or leave nothing selected
- run
IntentOS: Prepare Taskfrom the Command Palette - if needed, type the request into the small input box
- review interpretation, risk/approval boundaries, context summary, verification, and the prepared prompt
- use Copy Prepared Task when ready
Advanced routing/context details stay collapsed by default. The extension invokes intentos optimize ... --json; it does not duplicate IntentOS classification, policy, context, or routing logic in JavaScript.
intentos.executable defaults to intentos and can be changed when VS Code needs a specific virtual-environment executable path.
This first slice intentionally does not include a permanent sidebar, automatic project-file discovery, agent-specific Send/Execute wiring, telemetry, or a background service. See integrations/vscode/README.md.
Python API
from intentos import (
IntentRequest,
RunMetrics,
build_run_record,
build_skill_artifact,
optimize_prompt,
)
result = optimize_prompt(
IntentRequest.from_values(
"Refactor the auth module without changing behavior",
target_tool="codex",
constraints=["No new dependencies"],
success_criteria=["Relevant tests pass"],
)
)
if result.needs_clarification:
print(result.questions)
else:
print(result.policy.task_type, result.policy.risk_level)
print(result.routing.required_capability, result.routing.effort)
print(result.prompt)
skill = build_skill_artifact(result.intent, result.policy)
record = build_run_record(
result,
metrics=RunMetrics(success=True, quality_score=0.9),
)
print(skill.content)
print(record.to_json())
For project-aware prompting, use optimize_project_prompt(). For model selection, pass replaceable ModelMetadata entries. IntentOS intentionally does not hardcode volatile model names in the core.
Run records intentionally avoid storing raw prompts by default. They use fingerprints and compact metadata so future telemetry/dataset adapters can be added without making raw private agent traces a core requirement.
The deterministic task/risk classifier is an advisory preparation mechanism, not a security authorization boundary.
Engineering philosophy
IntentOS prefers:
- minimal sufficient context
- small coherent changes
- KISS and YAGNI before abstraction
- contextual SOLID / DRY / Clean Code
- explicit scope and approval boundaries
- secure defaults and least privilege
- reproducible and recoverable DevOps changes
- evidence-backed completion
- the lowest-overhead model that still meets the quality bar
- simple defaults with expert controls available when needed
It should not force Clean Architecture, microservices, extra abstractions, heavyweight process, or expert-only UX onto small tasks.
Architecture
The conceptual pipeline is:
User Intent
↓
Intent Normalizer
↓
Task + Risk Classifier
↓
Context Selector
↓
Policy Engine
↓
AI / Model Router
↓
Prompt / Skill Compiler
↓
Verification Contract
↓
Evaluation + Run Record
See docs/ARCHITECTURE.md, docs/UX.md, docs/DECISIONS.md, docs/EVALUATION.md, and docs/HUGGINGFACE_RESEARCH.md.
What IntentOS is not
IntentOS is not:
- an IDE
- an LLM or coding-agent replacement
- a general autonomous-agent framework
- a general MCP runtime
- a telemetry backend
- a CI/CD platform
- a project-management suite
- a framework that forces one software architecture
- a giant prompt-template collection
Development
The core currently has no third-party runtime dependencies. MCP support is an optional extra rather than a core dependency. The minimum VS Code extension uses plain JavaScript and built-in VS Code/Node APIs.
PYTHONPATH=src python -m unittest discover -s tests -v
GitHub Actions runs the full core suite on Ubuntu with Python 3.11, 3.12, and 3.13, focused Windows/Python 3.13 regression coverage, CLI smoke checks, MCP protocol/stdio parity checks, and a dependency-free VS Code extension syntax check.
Project status
The initial Phase 0–6 roadmap and independent-audit stabilization gate are complete. Phase 7 is complete: MCP parity was proven, VS Code is publicly distributed with a visible status-bar launcher, and the accepted workflow remains Prepare → Review → Copy. The evidence gate did not justify additional adapters or execution capabilities.
Current baseline: 120 Python unit tests + CLI smoke + MCP protocol/stdio parity checks + VS Code contract, syntax, and package checks, with Linux and Windows CI coverage. CI also builds and inspects wheel/sdist artifacts, then installs and smoke-tests each from clean environments without publishing.
Core 1.0.1 is in patch-release preparation for the review-only classification/policy correction. See the 1.0.1 release notes; tagging and publication await separate maintainer authorization.
The v1 public compatibility contract is frozen in docs/PUBLIC_CONTRACT.md. IntentOS 1.0.0 is the current stable core release; VS Code extension 0.1.1 is published. Phase 7D was intentionally deferred and closed without implementation because no additional adapter demand met the evidence threshold. Phase 7 is formally complete. Phase 8 — Adoption & Outcome Validation is in progress at the validation-protocol stage; no new runtime capability is approved. See the release notes and release procedure.
See docs/STATUS.md for the concise handoff, docs/DOGFOODING.md for real-world findings, docs/MCP_DOGFOODING.md for MCP parity evidence, docs/HUGGINGFACE_RESEARCH.md for the ecosystem research pass, docs/UX.md for usage/access principles, docs/INDEPENDENT_AUDIT.md for the review contract, and docs/ROADMAP.md for the roadmap.
Contributing
Contributions are welcome, especially:
- real-world failure/regression fixtures
- target-tool profiles where generic behavior is demonstrably insufficient
- provider/model metadata adapters
- context-selection improvements backed by tests
- evaluation and workflow improvements with measurable evidence
- portable Agent Skills and integration adapters that preserve the vendor-neutral core
- usability improvements that reduce friction without duplicating core behavior
Please read CONTRIBUTING.md before opening a PR.
License
MIT
Metadata
Release files for intentos-engineering 1.0.1
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | Actions |
|---|---|---|---|---|
| intentos_engineering-1.0.1.tar.gz | 54.0 kB | With provenance | Details for intentos_engineering-1.0.1.tar.gz |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Actions Reset |
|---|---|---|---|---|
| intentos_engineering-1.0.1-py3-none-any.whl | Python 3 | none | any | Details for intentos_engineering-1.0.1-py3-none-any.whl |
Total release size: 89.9 kB
Release files / intentos_engineering-1.0.1.tar.gz
| Download URL | intentos_engineering-1.0.1.tar.gz |
|---|---|
| Size | 54.0 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
4cd01b26e657b5e678bfa0a41b272124247d547c01e045cd0d05f4640e0080cf
|
|
BLAKE2b-256 checksum How to use checksums |
42f0756c20e783fdd1363438e9562746d97173f746d05c81fad9332bb3949a35
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.16
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Nov 3, 2026.
Transparency logRelease files / intentos_engineering-1.0.1-py3-none-any.whl
| Download URL | intentos_engineering-1.0.1-py3-none-any.whl |
|---|---|
| Size | 35.9 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
2b800cde3da81c2f4ef9613f69b68fedbc4c6511bed4ca38e5c13df1c3599920
|
|
BLAKE2b-256 checksum How to use checksums |
b0bba21541c9e3af6b8d7026606ad08e435e97cc3b9e22902aba8c7595ea4c5d
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.16
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Nov 3, 2026.
Transparency logSecurity for intentos-engineering 1.0.1
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
Full provenance
Both files in this release have been uploaded with provenance metadata.
Attestation for intentos_engineering-1.0.1.tar.gz
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Nov 3, 2026.
Transparency logA note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
To learn more about protecting yourself from malicious actors, visit our package security documentation.