Version Control for Every AI Agent

Every save creates a new version, and Arahi retains the full history by default — not the last ten, not the last hundred. Every prompt tweak, tool change, schema edit, permission update, and connection swap is captured as an immutable snapshot, timestamped, attributed to the person who made it, and labeled with an optional commit message. On paid plans, version history is retained for the life of the workspace; on the free plan, the most recent 90 days are retained with older versions compacted into a summary record. You can pin specific versions as named releases (for example, v1.4-stable or pre-onboarding-migration) so they survive compaction regardless of age. If your compliance posture demands longer retention with tamper-evident hashing, the Enterprise plan writes every version to a customer-owned S3 bucket with object lock enabled. In practice, most teams never hit a retention wall — they reach for the diff view, roll back a regression, and move on.

Yes. Every agent in Arahi has at least two environments — staging and production — and you can spin up ephemeral preview environments on demand. Staging runs the same agent logic against either real connected data (read-only mode by default) or a sandboxed fixture dataset you define once and reuse. You can chat with the staging version, run the test suite, and invite teammates to click through scenarios, all while production continues to serve real traffic off the previous version. When you're satisfied, you promote staging to production with one click — Arahi performs a blue-green swap so in-flight conversations finish on the old version and new sessions start on the new one. Nothing in production moves until you explicitly promote, and if the promotion introduces a regression, one-click rollback restores the prior version within seconds.

Everything that defines agent behavior is versioned, not just the system prompt. That includes the prompt and instructions, the list of tools and connectors the agent can call, the permission scopes on each connector, the workflow graph and branching logic, input and output schemas, variables and secrets references (values are vaulted separately), the knowledge sources and retrieval settings, guardrails and content filters, pricing and rate-limit settings, and any human approval rules attached to sensitive steps. Each version is a complete, self-contained definition — you can roll back to last Tuesday's version and get the prompt, tools, permissions, and approvals from that moment, not a Frankenstein mix of old prompt and new tools. Secrets and API credentials are referenced by name rather than copied into each version, so rotating a credential doesn't force a re-version of every agent that uses it.

Rollback is one click from the history timeline. Pick any prior version, preview the diff against whatever is live, and confirm — Arahi makes that version the new production version within a couple of seconds. Under the hood, rollback is a forward-only operation: instead of rewriting history, Arahi creates a new version whose definition matches the target, preserving the full audit trail. That means you can roll back the rollback if you change your mind, and every promotion (forward or backward) is logged with a reason field. In-flight runs started on the broken version are allowed to finish or, for destructive-action agents, paused and surfaced for manual review so nothing half-executes. Scheduled and queued runs automatically pick up the restored version on their next tick. If you want rollback to happen automatically when error rates or eval scores regress, you can wire Arahi's health checks to trigger an auto-rollback with a Slack notification.

Yes — every version records the author, timestamp, commit message, IP address, and a git-style diff of the change. Open any version in the history timeline and you get a side-by-side view of what moved: added tools highlighted green, removed permissions in red, prompt edits shown line-by-line, workflow graph nodes diffed by shape and connection. Filter by author to see everything a specific teammate has shipped, or filter by agent to audit a single surface end-to-end. The activity log is exportable to CSV for compliance reviews and streams to SIEM targets (Datadog, Splunk, S3) on the Business plan and above. For regulated teams, change attribution is tied to SSO identity rather than a local Arahi account, so offboarding a user through your IdP immediately revokes their ability to push new versions while preserving their historical authorship for the audit trail.

Yes, and the two features are designed to reinforce each other. Human approval rules are part of the versioned definition, so you can see exactly which version required approval for which action and roll that policy back if it was loosened too aggressively. When a new version is promoted to production, in-flight approval requests started on the old version continue to resolve against the old rules — Arahi won't retroactively change the gate a reviewer agreed to. Going the other direction, you can require human approval on the promotion itself: configure any environment to block promotions until a designated reviewer signs off in Slack or email, which catches risky changes before they ever reach production. Rollbacks can be made approval-gated too, so a panicked revert at 2am still goes through the same review path as a forward deploy. See the full reviewer workflow on Human Approval.