pramaan
Start a brief

The Pramaan platform

One system.
Deliberate boundaries.

Pramaan separates product decisions, agent execution, governed capability effects, customer code, and deployment authority—then connects them with versioned contracts and receipts.

View the architecture Start a brief

Hybrid architecture

Pramaan sits in two places for two different jobs.

The delivery control plane coordinates change around the repository. The hosted capability runtime governs selected application effects. They share contracts and evidence, not ambient authority.

Pramaan delivery and runtime paths
Delivery control planeBuild-time
Human→Loop→Agent worker→Repo + CI/CD

Pramaan coordinates change. It does not intercept every application request.

Hosted capability pathRuntime · when selected
Customer app→Gateway→Kernel→Provider

Hosted capabilities use Pramaan's governed runtime and credential custody.

Direct provider pathRuntime · default where appropriate
Customer app→Installed adapter→Provider

Loop monitors the integration and prepares a tested change when the contract moves.

Agent execution plane

Workers write code. The kernel governs effects.

An isolated worker receives a signed, bounded work order, checks out an exact code identity, invokes a harness and skills, and returns a candidate plus receipts.

Replaceable execution

Hosted worker, customer VPC, or GitHub runner. Model and harness can change without rewriting the lifecycle or evidence contract.

Pramaan execution plane architecture
Intent
01Human authorityObjective · policy · budget
02Pramaan LoopLifecycle controller
bounded work order→
Ephemeral workerisolated
01Checkout exact SHA
02Inspect + patch
03Test + review
04Return evidence
HarnessSkillsCost meter
proposal + receipts→
Delivery
03RepositoryPR · CI · approval
04Customer releaseCanary · observe · rollback

State ownership

One authority for every kind of truth.

The platform avoids two controllers both believing they own the same action. Each domain writes its state and exchanges immutable receipts across the seam.

01Founder
Accepts the plan, merges every pull request, owns the repository
02Loop
Application delivery lifecycle and observed outcome
03Kernel
Capability authority, mutations, metering, and platform evidence
04Customer app
Business records, end-user data, and product behavior

Trust model

The promises that survive a tool change.

Harnesses, models, capabilities, and dashboards are replaceable. These system properties are not.

01IDENTITY

Every action is attributable.

Human or policy authority → delegated agent → session → invocation remains attached to the work.

02AUTHORITY

Agents cannot widen their own envelope.

Scope, providers, regions, data classes, time, calls, tokens, and cost are bounded by an independent principal.

03EFFECTS

Mutations survive retries.

Plan digest and step identity make apply, resume, and lost-response reconciliation deterministic.

04EVIDENCE

Claims bind to exact subjects.

Gate, approval, release, and observation receipts identify the exact build and manifest they support.

05CUSTODY

Provider secrets stay in their boundary.

Credentials do not cross into application code, prompts, logs, or the public gateway process.

06HONESTY

Unavailable means unavailable.

Required dependencies fail closed. A missing provider does not silently become an in-memory production fallback.

What this enables

Maintenance becomes a governed delivery event.

When a dependency ships a breaking change, Loop can detect the structured diff, open a bounded run, let a worker produce the smallest compatible patch, execute the gates, and prepare a PR or release. Customer approval and redeploy remain explicit wherever code changed.

See connected repositories

Start here

Describe the product. Approve the plan.

Start a brief