pipeline
generic CI/CD
Generic CI/CD YAML bolted onto an agent as an afterthought.
a2a pipeline
Build → review → deploy is one governed pipeline, purpose-built for agents.
build → review → deploy
AI agent CI/CD as one governed pipeline.
Agents don't need generic CI/CD bolted on — they need a pipeline that understands an agent's source, runtime, Agent Card, and skills. On a2a, a git push starts a Gitea Actions build, Argo/Knative reconcile the generated runtime state, live verification checks the expected image, card, and skills, and an asynchronous source review adds findings to the same deployment timeline. The release record and signed execution evidence stay explicit: deploy facts live on the deployment; actual agent invocations emit ExecutionReceipts.
git push · build · advisory review · reconcile · live verification
0
git repo per agent
deployment timeline per attempt
0
evidence types kept distinct
the problem
Generic CI/CD wasn't built to deploy agents.
A standard CI/CD pipeline ships a service: build an image, apply it, watch a health check. Bolt that onto an agent and the agent-shaped evidence gets scattered — source revision in git, image status in CI, rollout in Argo, runtime readiness in Kubernetes, card and skill discovery at the service edge, and source-review findings somewhere else. You end up with a pipeline that says 'green' without one durable place to inspect what was built, what is live, what the reviewer found, and what still needs an invocation test.
Source-review findings are easy to lose when review and deployment history live separately.
A health check alone doesn't confirm the expected image, Agent Card, and skill surface agree.
Deploy scripts and credentials drift; secrets get baked into images and git.
A CI log is not a deployment record, and a deployment record is not an execution receipt.
the a2a way
Push, and the whole governed pipeline runs.
The agent's source lives in a Gitea repo. A push records a deployment attempt, Gitea Actions builds the image, Argo reconciles the runtime onto Knative, and the control plane verifies the expected image, runtime, Agent Card, and skills. Advisory source-review findings and bounded, scrubbed logs join the deployment timeline. Invoke a skill through the API, MCP, or /invoke entry point for separate signed execution evidence.
Push is the triggerBuild runs on the pushSource review joins the timelineArgo/Knative reconciles the rolloutLive deployment verificationTwo evidence types, kept distinct
Push is the trigger
Every managed agent gets its own git repo in Gitea. A push is the pipeline's entry point — the source commit becomes the revision recorded on the deployment attempt and its timeline, so the build and rollout can be traced back to the code that triggered them.
Build runs on the push
Gitea Actions builds the image from the pushed source: dependencies resolved, the agent packaged, an image produced and pushed to the registry. The deployment log view fetches a bounded, scrubbed tail of the Actions output, so the build failure stays attached to the deployment that triggered it.
Source review joins the timeline
The agent-reviewer inspects the committed source asynchronously and stores its status, summary, and severity-counted findings in a dedicated review record linked to the deployment timeline. Today that review is advisory: it gives an owner concrete findings to act on, but it does not block the rollout.
Argo/Knative reconciles the rollout
Argo reconciles the generated runtime state onto Knative and the revision rolls out. The deployment tracks the source SHA, expected image, runtime revision, Argo state, and Knative readiness so an owner can see whether build output and live runtime converged.
Live deployment verification
The control plane checks the reconciled runtime, expected image, live Agent Card, and advertised skills before marking the deployment live. Those checks are stored in the deployment's verification record. A smoke test through the API, MCP, or /invoke entry point is a separate execution with its own signed evidence.
Two evidence types, kept distinct
The deployment record carries source revision, image, stage events, review findings, log tails, and verification state. A covered agent or smoke invocation separately signs agent, caller, skill, input, the grants that authorized it, outcome or result preview, and timing. The deploy itself does not mint a receipt; optional activity fields are not populated by default.
side-by-side
Generic CI/CD bolted on vs. an agent-native pipeline.
source review
generic CI/CD
Code review and deployment history live in unrelated systems.
a2a pipeline
Advisory agent-review findings are linked into the deployment timeline.
rollout
generic CI/CD
kubectl apply or a bespoke deploy script you maintain yourself.
a2a pipeline
Argo/Knative reconcile the commit as desired state — GitOps for agents.
verification
generic CI/CD
A successful image build is treated as proof the service is usable.
a2a pipeline
Runtime, expected image, Agent Card, and advertised skills are checked live.
audit trail
generic CI/CD
A green checkmark in a log that rotates away in 90 days.
a2a pipeline
A durable deploy timeline, plus separate signed receipts for real agent invocations.
dimension
generic CI/CD
a2a pipeline
pipeline
Generic CI/CD YAML bolted onto an agent as an afterthought.
Build → review → deploy is one governed pipeline, purpose-built for agents.
source review
Code review and deployment history live in unrelated systems.
Advisory agent-review findings are linked into the deployment timeline.
rollout
kubectl apply or a bespoke deploy script you maintain yourself.
Argo/Knative reconcile the commit as desired state — GitOps for agents.
verification
A successful image build is treated as proof the service is usable.
Runtime, expected image, Agent Card, and advertised skills are checked live.
audit trail
A green checkmark in a log that rotates away in 90 days.
A durable deploy timeline, plus separate signed receipts for real agent invocations.
questions
Frequently asked.
What does CI/CD for an AI agent actually look like on a2a?
Each managed agent has its own git repo in Gitea. A push records a deployment attempt and triggers the Gitea Actions image build; Argo reconciles the image onto Knative; the control plane verifies the expected runtime image, Agent Card, and advertised skills; and an asynchronous source review adds findings to the deployment timeline. Commit, image, stages, review, logs, and verification live in deployment records. Signed ExecutionReceipts are separate and are produced only when an agent or smoke skill is actually invoked.
Is this GitOps for agents?
Yes. The source commit identifies the managed build, the runtime repository carries the generated deployment state, and Argo/Knative converge the running service onto the expected image. The deployment record preserves the source SHA, expected image, stage events, logs, and verification results. That is distinct from an ExecutionReceipt, which signs an agent invocation rather than a release.
Does the automated code review block a deploy?
Not today. The agent-reviewer runs asynchronously after source is committed, and its status, summary, and findings are persisted in an AgentReviewRun linked to the deployment timeline. The result is advisory: owners can act on critical or warning findings, but the deployment does not wait for the reviewer and is not automatically blocked by its verdict.
How do I know the deployed agent actually works?
Deployment verification checks that the expected image is reconciled, the Knative runtime is ready, the live Agent Card loads, and the card advertises callable skills. Those results are stored on the deployment and rendered as timeline stages. To verify a skill's behavior, run an invocation-based smoke test; that invocation is separate from deploy verification and can produce its own signed ExecutionReceipt.
Where do the agent's credentials come from at deploy?
Runtime secrets and delegated authority are managed outside the source commit and deployment image. Scoped grants are attached to calls that need bounded authority, and those grant IDs can be part of the signed ExecutionReceipt for the invocation that used them. The deployment timeline records rollout state; it is not a signed record of runtime grant use.
keep reading
Related guides.
All guides live in the guides index.
build → review → deploy
Ship agents with the release record and run evidence kept clear.
a2a cloud deploys managed agents from a git push. Gitea Actions builds the image, Argo/Knative reconcile the rollout, live verification checks the expected image, runtime, Agent Card, and skills, and an advisory source review lands beside bounded logs in the deployment timeline. The deployment record preserves release facts; a smoke invocation through the API, MCP, or /invoke entry point produces separate signed execution evidence.