Adopting agentic development patterns from fullsend for Tekton

[vdemeester]

Following up on last week's working group presentation on fullsend — an exploration on fully autonomous agentic development.

Context

fullsend explores how to move from human-driven development toward zero-human-intervention for routine changes. The key thesis: code generation is largely solved; the hard problems are review, intent, governance, and security.

The design covers several areas:

• Intent Representation — tiered authorization, git as intent ledger
• Security Threat Model — zero trust, prompt injection as priority concern
• Agent Architecture — specialized review sub-agents, repo-as-coordinator
• Autonomy Spectrum — binary per-repo with CODEOWNERS escape hatch
• Code Review — sub-agent decomposition (security, correctness, style, etc.)
• Tekton Pipeline Review — domain-specific challenges (embedded shell, stringly-typed interfaces, trusted task model)
• Migration Path — 5-phase incremental adoption from observation to full autonomy

Discussion

I'd like to gather thoughts on a few questions:

1. Which parts of this approach could benefit the tektoncd org? For example, automated review sub-agents for PRs, ADR drift detection, or Tekton task/pipeline validation.
2. What concerns or blockers do you see? Security model, governance, trust in automated merges, etc.
3. Where would you want to start? Shadow review (agents comment but don't merge) seems like a natural first step.
4. Tekton-specific challenges — Tekton tasks/pipelines have unique review needs (shell scripts, result propagation, parameter threading). How should we handle these?

The fullsend repo has the full design docs. Feedback on the approach, concerns, or ideas for where to pilot this are all welcome.

[maruiz93]

Thanks for writing this up, Vincent. Some thoughts on your questions below, and I'm also folding in answers to the follow-up questions from the working group meeting.

Docs for reference: https://fullsend.sh

Which parts could benefit tektoncd?

I'd start with triage and review agents on tektoncd/pipeline. That repo is already well prepared — it has AGENTS.md and agent-specific context docs that agents read automatically. These agents are non-destructive: they comment on issues and PRs but don't merge or push code.

Someone asked during the meeting whether the triage agent can handle labeling and detect good-first-issue candidates — yes. It includes a built-in skill that discovers the repo's existing labels via gh label list and recommends whichever ones fit. If tektoncd/pipeline has a good-first-issue label, the triage agent will assess incoming issues and apply it when appropriate, with no extra configuration needed.

On the Copilot comparison that came up: fullsend goes beyond code review — it's a platform for autonomous development with triage, code, fix, and retro agents. Copilot code review (which Tekton already has via CNCF) is advisory review only. Fullsend is open source, customizable per-repo, supports multiple inference providers, and includes a migration path from observation-only to full autonomy with CODEOWNERS as the guardrail.

Concerns and known limitations

• GitHub Actions resources. This came up during the meeting — each agent run is a workflow run. The roadmap includes Kubernetes/OpenShift execution as a future milestone, which would decouple agent runs from GitHub Actions. A roadmap refresh is in progress. For now, triage+review on one repo would be a modest addition.
• Observability. Also raised during the meeting — not yet mature, but actively being worked on. The design direction is OpenTelemetry-based distributed tracing with several ADRs already accepted (ADR 0050, ADR 0021). The roadmap has more detail on where this is headed.
• Security on public repos. A couple of meeting questions touched on this. Agents do not run automatically on PRs or issues from external contributors — ADR 0054 requires write-level repo permission on all dispatch paths. This is intentional — it limits cost exposure and the prompt injection attack surface. Maintainers can still trigger agents on external contributions manually via /fs-review. Relatedly, the fix agent does not proactively harvest PR comments from other reviewers to build its context — it doesn't actively seek them out, though there's no hard constraint if comments are already visible on the PR. The primary control is the authorization gate: only authorized users can trigger agent runs.
• GCP project for inference. Fullsend uses Vertex AI for inference, which requires a GCP project. The Getting Inference guide covers the setup.

Where to start

Shadow review — agents comment but don't merge — is the natural first step. Concretely:

1. Enroll tektoncd/pipeline in the shared token mint and provision inference on a GCP project
2. A pipeline maintainer runs fullsend github setup tektoncd/pipeline --agents triage,review, installs the GitHub Apps, and merges the scaffold PR
3. Test with /fs-triage on an issue and /fs-review on a PR

The Getting Started guide walks through this end-to-end.

The recommendation is to evaluate the default agents first before investing in any customization — they work out of the box and the pipeline repo's AGENTS.md already provides the context they need. You can also run agents locally against a cloned repo with --no-post-script to test behavior before committing to a full onboarding.

Customization options (for later)

This also came up during the meeting — what's the maintenance burden of customizing agents?

ADR drift detection at PR time is something the review agent handles naturally — it reads repo context including ADRs and flags PRs that contradict accepted decisions.

For deeper Tekton-specific validation (e.g., result propagation, parameter threading, embedded shell checks), the lighter approach is adding a custom skill rather than replacing the full review agent prompt. Skills concatenate with the upstream defaults (ADR 0045), so you only maintain the Tekton-specific additions — when fullsend ships prompt improvements upstream, they flow automatically. A thin harness override inherits from upstream:

# .fullsend/customized/harness/review.yaml
base: https://raw.githubusercontent.com/fullsend-ai/fullsend/<sha>/internal/scaffold/fullsend-repo/harness/review.yaml#sha256=<hash>
skills:
  - skills/tekton-pipeline-review

With the skill itself in .fullsend/customized/skills/tekton-pipeline-review/SKILL.md. The standard review skills still apply — you only maintain the Tekton-specific additions.

Harness inheritance via base: is recent — the fullsend team is dogfooding it on their own review agent but it's not yet widely adopted across other orgs. More detail on the layering model in ADR 0035.

[maruiz93]

It's been a couple of weeks since my last comment — a few updates on what's changed in fullsend since then, and a concrete example of the observability story tying into @richardchen874-sys's point.

Updates since July 9

Observability. The tracing system has progressed since I last commented. The bespoke L1 recorder was replaced with the OpenTelemetry Go SDK on July 17, so spans now export at runtime through standard OTLP exporters rather than a post-run replay step. All the reusable agent workflows (triage, review, code, fix, retro, prioritize) accept OTEL_EXPORTER_OTLP_TRACES_ENDPOINT and OTEL_EXPORTER_OTLP_TRACES_HEADERS — orgs opt in by setting these as Actions variables/secrets. It's not enabled by default; it's a conscious choice per deployment. There's still room for improvement — sub-agent span granularity is deferred to a later phase (ADR 0050) and cost aggregation across backends needs refinement — but the foundation is usable.

Roadmap refresh. The July 2026 roadmap merged. Observability is now priority #3 (up from being buried in future milestones), with cost measurement/aggregation (#2668) and telemetry phases 2 & 3 as active work items. K8s/OpenShift execution remains in the "Later" horizon.

BYOA (Bring Your Own Agent). This is now the #1 priority. A BYOA guide and agent CLI reference landed. Agent registration (ADR 0058) shipped in three phases, and selective agent enablement via config is now possible (#4026). This is relevant to the Tekton conversation because it means custom agents (e.g., a Tekton pipeline validator) can be added as first-class agents alongside the defaults, not just as skills on the review agent.

GitLab CI/CD templates. Scaffold templates for GitLab CI landed (#3193), making fullsend not GitHub-exclusive anymore — relevant if any Tekton repos or forks live on GitLab.

Security. A SECURITY.md was added for vulnerability reporting. ADR 0073 introduced named privilege levels for mint roles, tightening least-privilege boundaries per agent type.

Harness inheritance. I mentioned base: in harness overrides was recent and not widely adopted — that's still the case, but URL-based harness composition (resolving scripts, skills, and declarative resources from URL-referenced bases) has shipped (#2525, #2690, #2707), making the customization story I described for Tekton-specific skills more robust.

Observability in practice — a concrete trace

To @richardchen874-sys's point about logging route choice, provider/model, and usage: this is exactly what fullsend traces capture. I'm sharing run-telemetry.jsonl from a review agent run on PR #5643 (today). The file is standard OTLP/JSON and can be ingested into any OTLP-compatible backend (MLflow, Jaeger, Arize Phoenix, Langfuse, Grafana Tempo, etc.).

Here's what you can extract from the span attributes:

What	Attribute	Value (this run)
Agent	gen_ai.agent.name	review
LLM provider	gen_ai.system	anthropic
Model	gen_ai.request.model	claude-opus-4-6
Output tokens	gen_ai.usage.output_tokens	39,394
Cache read	gen_ai.usage.cache_read.input_tokens	1,851,639
Cost	fullsend.cost_usd	$6.25
Turns	fullsend.num_turns	42
Tool calls	fullsend.tool_calls	140
Work item	fullsend.work_item_id	PR #5643 URL
Security trace	fullsend.security_trace_id	UUID (correlates with security audit findings)

The gen_ai.* attributes follow OTEL GenAI semantic conventions, so LLM-aware backends recognize them automatically and surface GenAI dashboards (token rollups, model breakdown, per-agent cost) with no extra configuration.

To try it locally:

pip install mlflow && mlflow server
gh run download <run-id> --repo fullsend-ai/.fullsend -n fullsend-review

curl -s -X POST http://localhost:5000/api/2.0/mlflow/experiments/create \
  -H "Content-Type: application/json" -d '{ "name": "fullsend-traces" }' 

while IFS= read -r line; do
  curl -s -X POST http://localhost:5000/v1/traces \
    -H "Content-Type: application/json" \
    -H "x-mlflow-experiment-id: 1" -d "$line"
done < agent-review-*/run-telemetry.jsonl

On @richardchen874-sys's question about what's hardest for the community — I think at the shadow-review stage (agents comment but don't merge), cost predictability is the most immediate concern, followed by provider compatibility. Routing quality matters less when you're observing behavior rather than trusting it. The distributed tracing guide covers the full setup.