When an agent triggers an ArgoCD application sync, Dock holds the rationale, the diff summary, and the on-call approval. ArgoCD stays the deployment engine. GitHub stays the source of truth for manifests. Dock records why the sync happened, which agent proposed it, and who approved it. The result is a GitOps pipeline where every reconciliation has a sentence next to it that a human signed.
ArgoCD and GitHub stay the system of record for the raw data. Dock is the system of record for what the agent interprets. Each Dock row carries a pointer back to the platform record, agent identity, decision, reviewer, and timestamp. The agent re-fetches platform data via fresh API reads when it needs current state.
The Sync Decisions table
| sync_id | app | drift_detected | agent_rationale | on_call_approver | argocd_link |
|---|---|---|---|---|---|
| sync-8821 | payments-api | image tag behind main by 3 commits | Roll forward to ship the idempotency fix merged in #4412. Low blast radius, no schema change. | govind@ | argocd/app/payments-api |
| sync-8822 | checkout-web | configmap drift on feature flag | Hold. Drift is from a manual toggle during incident #INC-771. Reconciling would revert the mitigation. | sarah@ (declined) | argocd/app/checkout-web |
| sync-8823 | ledger-worker | helm chart bump 2.4.1 to 2.4.2 | Patch release, changelog is dependency bumps only. Auto-syncing in staging first. | auto (staging policy) | argocd/app/ledger-worker |
Each row points back to the ArgoCD application and the GitHub commit. The rationale is the agent's reading of the diff, not a copy of the diff itself.
One workflow: drift to decision
Argus, the deploy agent, watches the ArgoCD API for OutOfSync states. When checkout-web drifts, Argus opens a Dock row, fetches both manifests, summarizes the delta in plain English, and tags the on-call. Sarah reads the rationale, sees the link to incident INC-771, and declines. Dock records the decline with her signature. ArgoCD never reconciles. Standup pulls the declined filter to decide whether to promote the manual change into git or revert.
The loop runs in reverse for healthy syncs. Argus drafts rationale, the on-call approves, ArgoCD executes, and Dock stamps the post-sync health check. This is the dangerous ops contract applied to deploys.
Why this matters
GitOps promised an audit trail through git history. In practice, the trail tells you what changed, not why an agent decided to sync at 2am or why a human held the line. Dock fills that gap without replacing ArgoCD. The deployment engine keeps reconciling. The git repo keeps holding manifests. Dock holds the sentence that connects them to a decision. This is the same pattern we describe in Cloud 2.0 for engineering and in Dock for IT operations: platforms run, agents interpret, humans approve, Dock remembers.
It also makes agent audit and compliance tractable. When a regulator asks why a production sync happened on a Saturday, the answer is one row with a name, a rationale, and a link. The agent that proposed it has a stable identity through the agent identity lifecycle, so the trail survives rotation.
Start with one ArgoCD application. Wire Argus to draft rationale on every sync proposal. See the full pillar at Dock for DevOps.
FAQ
Does Dock replace ArgoCD? No. ArgoCD remains the reconciliation engine and the source of truth for cluster state. Dock records the interpretation layer that ArgoCD does not store: rationale, approver, and decision context. ArgoCD's sync options documentation covers how syncs execute; Dock covers why.
Does this break the OpenGitOps principles? No. The CNCF OpenGitOps principles require declarative, versioned, automatically pulled, and continuously reconciled state. Dock does not touch any of those. Manifests stay in git. ArgoCD still pulls and reconciles. Dock sits beside the pipeline as an audit surface.
What if the agent's rationale is wrong? The on-call reviews it before approving. Declined syncs are logged with the human's reason, which becomes training signal. The agent identity is bound, so a wrong call is attributable.
Can Dock auto-approve low-risk syncs? Yes, with a policy row that defines what counts as low-risk, for example staging-only patch releases. The policy itself is reviewable and versioned in Dock.
