Jarvis Core

jarvis-agent-core is the small typed, dependency-free Python contract/runtime library shared by standalone Jarvis and AI Stack Server. It standardizes portable agent behavior without owning product-specific tools, storage, credentials, deployment policy, model-provider SDKs, or OS isolation.

Install

Python 3.10+ is required. The current Core release is 0.11.0.

python -m pip install "jarvis-agent-core==0.11.0"

For development:

git clone https://github.com/abdullahalrifat/jarvis-core.git
cd jarvis-core
python -m pip install -e . -r requirements-dev.txt
python -m pytest

Capabilities

Core provides typed deterministic contracts/primitives for token accounting, context compaction, artifacts, evidence/verification, model routing/calibration, failure recovery, multi-agent orchestration, instructions/memory, MCP permissions, schedules/remote execution, leases, proof records, citations and evaluation cases. The 0.10.x line also exposes the shared per-task sandbox policy used by Jarvis and AI Stack Server.

Provider-neutral model contracts

Core 0.11.0 adds dependency-free contracts for model providers:

• ModelRequest describes a provider-independent completion request.
• ModelResponse carries normalized output, tool calls and usage information.
• ModelUsage represents token accounting without depending on a provider SDK.
• ToolCall represents normalized model-requested tool invocation data.
• ModelProvider defines the provider boundary consumed by higher-level runtimes.

These are contracts, not provider implementations. Anthropic, Ollama, OpenAI-compatible endpoints, LiteLLM and other concrete integrations belong in consumer/runtime projects. This keeps Core portable and prevents provider SDKs from becoming transitive dependencies of every Jarvis installation.

Conceptually:

jarvis-core
    │ provider-neutral contracts
    ▼
jarvis
    │ concrete provider adapters
    ▼
ai-stack / external endpoints
    ├── Ollama
    ├── LiteLLM
    └── hosted model APIs

Consumers should depend on the Core contracts rather than importing provider-specific SDK types into shared agent logic.

Core deliberately does not access repositories, execute commands, call model endpoints, start MCP processes, persist product sessions, run cloud workers, enforce tenancy, or approve changes. Jarvis/Server must wire contracts into the real execution path; OS sandbox enforcement remains a consumer/runtime responsibility.

See docs/contract-boundaries.md for the enforcement and trust boundary.

Contract enforcement matters

A Core field is not automatically a security control. Consumers must enforce approval before dispatch, durable lease predicates for cloud state, real execution-derived proof, and credential isolation. Independent evidence must also have a verifiable identity and must not be satisfied by reference-only or duplicate evidence for the same claim.

Compatibility and release policy

• semantic versioning is used while the pre-1.0 API stabilizes;
• patch releases should remain compatible within a minor line;
• breaking contracts require coordinated Core/Jarvis/Server releases;
• publish Core first, then pin consumers to the released package version;
• an existing GitHub Release is never silently replaced;
• PyPI publication uses GitHub Actions Trusted Publishing; no long-lived PyPI API token is stored in GitHub.

Current release coordination:

Development

black --check src tests
ruff check src tests --select E9,F63,F7,F82
pytest -q --cov=jarvis_core --cov-report=term-missing --cov-fail-under=85
python -m build
python -m twine check dist/*

Read CONTRIBUTING.md, CODE_OF_CONDUCT.md, SUPPORT.md and SECURITY.md before contributing/reporting issues.

Releases and supply chain

Core releases are versioned explicitly. A version bump merged to main is validated against the exact commit, built as a wheel and sdist, checked with Twine, smoke-tested in a clean environment, checksummed, provenance-attested and published as a GitHub Release. The same release workflow then publishes the exact validated distributions to PyPI using Trusted Publishing. Existing immutable releases are never replaced.

The package metadata points at README.md, so the README from the exact release commit is also used as the PyPI project description. Documentation changes that need to appear on PyPI therefore require a new package version; an existing published release should not be mutated.

Release flow

version/code/documentation PR
    -> CI
    -> merge to main
    -> validate exact merged SHA
    -> build wheel/sdist
    -> clean-environment install check
    -> SHA-256 checksums + provenance attestation
    -> GitHub Release vX.Y.Z
    -> PyPI Trusted Publishing
    -> consumer repositories update their pinned Core version

For an already-created GitHub release that needs a publication retry, maintainers can use the workflow_dispatch input on .github/workflows/release.yml and select the immutable release tag. This is for republishing an existing version only; a documentation or code correction must use a new semantic version.

Consumers should depend on the PyPI package rather than a Git checkout or mutable branch. During local development, use an editable install of a checked-out jarvis-core repository.

License

Jarvis Core is available under the MIT License.