📊 Agentic Workflow Lock File Statistics Analysis - January 2026

[github-actions[bot]]

Executive Summary

Comprehensive statistical analysis of 130 agentic workflow lock files (.lock.yml) in the .github/workflows/ directory reveals robust adoption patterns and consistent structural characteristics across the repository.

Key Findings:

• 130 lock files totaling 9.05 MB analyzed
• Average file size: 71.3 KB per workflow
• Most common trigger: issues (99.2% of workflows)
• Dominant safe output: noop (93.8% of workflows)
• Primary MCP server: GitHub MCP (3,224 references across workflows)
• Typical workflow structure: ~8 jobs, 10-20 minute timeout

---

Full Report

File Size Distribution

Overview Statistics

Metric	Value	Details
Total Files	130	All .lock.yml files in workflows directory
Total Size	9,491,774 bytes	~9.05 MB
Average Size	73,013 bytes	~71.3 KB per file
Median Range	60-80 KB	57 files (43.8%)
Smallest	24,418 bytes	example-permissions-warning.lock.yml (23.8 KB)
Largest	125,224 bytes	copilot-session-insights.lock.yml (122.3 KB)

Size Distribution

Size Range	Count	Percentage	Notes
< 30 KB	3	2.3%	Minimal example workflows
30-60 KB	29	22.3%	Simple workflows
60-80 KB	57	43.8%	Standard workflows (most common)
80-100 KB	33	25.4%	Complex analysis workflows
> 100 KB	8	6.2%	Feature-rich, multi-step workflows

Notable Large Workflows:

• copilot-session-insights.lock.yml - 122.3 KB
• intelligence.lock.yml - 107.8 KB
• daily-copilot-token-report.lock.yml - 105.7 KB
• copilot-pr-nlp-analysis.lock.yml - 104.2 KB
• daily-news.lock.yml - 103.5 KB

---

Trigger Analysis

Trigger Type Distribution

Trigger Type	Count	Percentage	Usage Pattern
issues	129	99.2%	Issue-triggered workflows (dominant)
workflow_dispatch	110	84.6%	Manual invocation capability
schedule	89	68.5%	Scheduled/cron-based execution
pull_request	16	12.3%	PR-triggered workflows
push	1	0.8%	Commit-triggered (release workflow)

Key Insights

1. Issue-Centric Architecture: Nearly all workflows (99.2%) respond to GitHub issues, demonstrating the issue-driven nature of agentic workflows
2. Hybrid Trigger Model: Most workflows support multiple trigger types:
   • 84.6% allow manual execution via workflow_dispatch
   • 68.5% run on schedules for proactive automation
3. Pull Request Integration: Limited but strategic PR workflows (12.3%) focus on code review and analysis

Schedule Patterns

Analysis of 89 scheduled workflows reveals diverse timing strategies:

Schedule Frequency	Count	Example Cron	Use Case
Weekday mornings	4	0 9 * * 1-5	Daily reports at 9 AM Mon-Fri
Weekly Monday	4	0 9 * * 1	Weekly summaries
Every 12 hours	4	*/12 * * *	Regular monitoring
Daily specific time	77	Various	Distributed throughout day

Distribution Strategy: Schedules are intentionally staggered (9 AM, 11 AM, 1 PM, 2 PM, etc.) to distribute load and avoid concurrent resource contention.

---

Safe Outputs Analysis

Safe outputs define how workflows communicate results and take actions in the repository.

Safe Output Types

Type	Count	% of Workflows	Purpose
noop	122	93.8%	Log-only completion (no persistent changes)
create-pull-request	16	12.3%	Automated code changes via PRs
add-comment	9	6.9%	Comment on existing issues/PRs
create-issue	8	6.2%	Create new issues for findings
create-discussion	7	5.4%	Publish analysis to discussions
update-issue	4	3.1%	Modify existing issues
missing-tool	1	0.8%	Report unavailable capabilities

Analysis

1. Read-Heavy Operations: The overwhelming dominance of noop (93.8%) indicates most workflows are analysis and reporting agents rather than code-modifying agents
2. Careful Write Operations: Only 12.3% of workflows create PRs, showing conservative approach to automated code changes
3. Communication-First: Workflows prioritize transparency through comments (6.9%) and discussions (5.4%)

Discussion Categories

For the 7 workflows using create-discussion:

Category	Usage	Purpose
audits	Primary	Security and workflow audit reports
reports	Secondary	Various agent analysis reports
daily-news	Tertiary	Repository activity summaries

---

Structural Characteristics

Job Complexity

Metric	Value	Notes
Total Jobs (all workflows)	1,035	Combined across 130 workflows
Average Jobs per Workflow	8.1	Typical workflow has ~8 jobs
Minimum Jobs	3	Simplest workflows
Maximum Jobs	14	Most complex workflows
Workflows Analyzed	128	(2 workflows had parsing issues)

Typical Workflow Structure

Based on statistical analysis, a standard agentic workflow has:

Structure Profile:
├─ Size: ~71 KB (60-80 KB range)
├─ Jobs: ~8 jobs
├─ Triggers:
│  ├─ issues: opened, labeled
│  ├─ workflow_dispatch: manual execution
│  └─ schedule: daily at specific time
├─ Permissions:
│  ├─ contents: read
│  ├─ issues: read/write
│  └─ pull-requests: read/write
├─ Timeout: 10-20 minutes
├─ Concurrency: workflow-specific group
└─ Safe Output: noop (log-only)

Step Distribution

Common job types across workflows:

1. Activation job: Initial setup and permission validation
2. Agent job: Main AI agent execution with Claude/Copilot
3. Safe output jobs: Multiple jobs for different output types (discussion, issue, comment, PR, etc.)
4. Cleanup job: Finalization and cleanup operations

---

Permission Patterns

Analysis of requested permissions across all workflows:

Most Common Permissions

Permission	Occurrences	Type	Usage
contents	784	Read	Repository content access
issues	465	Read/Write	Issue management (dominant use case)
pull-requests	432	Read/Write	PR operations
discussions	259	Write	Discussion creation

Permission Philosophy

1. Read-Heavy: contents: read appears 784 times, enabling code analysis
2. Issue-Focused: issues permissions (465) align with issue-triggered architecture
3. Selective Write: Write permissions granted sparingly and purposefully
4. Security-Conscious: Minimal permissions principle evident throughout

---

Tool & MCP Configuration

MCP Server Usage

MCP Server	References	% of Total	Primary Use Case
github	3,224	94.3%	GitHub API operations (repos, issues, PRs)
playwright	210	6.1%	Browser automation for testing
deepwiki	6	0.2%	Documentation research
arxiv	6	0.2%	Academic paper research
context7	4	0.1%	Contextual information
tavily	2	0.1%	Web search
microsoftdocs	2	0.1%	Microsoft documentation
markitdown	2	0.1%	Markdown processing
ast-grep	2	0.1%	AST-based code search

Analysis

1. GitHub Dominance: GitHub MCP server referenced 3,224 times across workflows, representing 94.3% of all MCP server usage
2. Specialized Tools: Secondary MCP servers (Playwright, DeepWiki, arXiv) used for specific capabilities
3. Research Capabilities: Multiple research-focused MCPs (arXiv, DeepWiki, Tavily) enable knowledge-augmented workflows

Common Tool Allowlists

Based on permission patterns, typical workflows allow:

• GitHub API tools: Issue/PR/discussion management
• File operations: Read, Edit (selective Write)
• Search tools: Grep, Glob for code exploration
• Bash commands: Limited, specific command sets
• Web tools: WebFetch, WebSearch (in research workflows)

---

Timeout Configurations

Timeout Distribution

Timeout (minutes)	Count	Percentage	Use Case
10 minutes	168	32.4%	Most common - Standard workflows
15 minutes	142	27.4%	Moderate complexity
20 minutes	139	26.8%	Complex analysis
5 minutes	14	2.7%	Quick checks
30 minutes	15	2.9%	Heavy processing
45 minutes	7	1.3%	Extensive analysis
60 minutes	5	1.0%	Maximum duration
480 minutes (8 hrs)	1	0.2%	Long-running batch job

Typical timeout: 10-20 minutes (86.6% of workflows)

Concurrency Control

• 313 workflows explicitly set concurrency groups
• Most common pattern: group: "gh-aw-${{ github.workflow }}"
• Purpose: Prevent multiple simultaneous runs of the same workflow

---

Interesting Findings

1. Highly Standardized Architecture

The narrow size distribution (43.8% in 60-80 KB range) and consistent job counts (~8 jobs) indicate strong architectural standards and shared patterns across the repository.

2. Conservative Automation Philosophy

With 93.8% of workflows using noop safe outputs, the repository prioritizes analysis and reporting over automated modifications. This reflects a thoughtful approach to AI-driven automation.

3. Schedule Load Balancing

Scheduled workflows are deliberately staggered across different times (9 AM, 11 AM, 1 PM, 2 PM, 5 PM, etc.) to:

• Avoid resource contention
• Distribute CI/CD load
• Enable different analysis frequencies

4. Multi-Trigger Flexibility

84.6% of workflows support workflow_dispatch, enabling:

• Manual testing and debugging
• On-demand analysis
• Emergency workflow execution

5. GitHub MCP Ecosystem

The GitHub MCP server's 94.3% usage share demonstrates successful ecosystem integration, with workflows leveraging GitHub's native capabilities as the primary interaction layer.

6. Workflow Naming Patterns

• daily-* prefix: 16 workflows (scheduled daily tasks)
• smoke-* prefix: 10 workflows (testing/validation)
• copilot-* prefix: 7 workflows (Copilot-specific analysis)
• Campaign workflows: 3 workflows (.campaign.lock.yml suffix)

---

Historical Trends

First analysis run - no historical comparison data available yet.

This analysis will serve as the baseline for future trend tracking:

• Lock file count growth
• Average file size evolution
• Trigger pattern shifts
• Safe output distribution changes
• MCP server adoption trends

---

Recommendations

1. Standardization Wins

Finding: 43.8% of workflows fall within 60-80 KB size range with consistent ~8 job structure.

Recommendation: Document and formalize these patterns as "canonical workflow templates" for new workflow development.

2. Timeout Optimization

Finding: 86.6% of workflows use 10-20 minute timeouts.

Recommendation:

• Monitor actual execution times to identify workflows that could use shorter timeouts
• Consider dynamic timeout adjustment based on workflow complexity

3. Safe Output Expansion

Finding: Only 6.2% of workflows create issues, 5.4% create discussions.

Recommendation:

• Expand usage of create-discussion for audit results (currently only 7 workflows)
• Consider create-issue for actionable findings requiring follow-up

4. MCP Server Documentation

Finding: GitHub MCP dominates (94.3%), but 9 different MCP servers are in use.

Recommendation:

• Document MCP server capabilities and best practices
• Create decision matrix for when to use specialized MCPs (Playwright, DeepWiki, etc.)

5. Schedule Distribution Review

Finding: Schedules heavily favor weekday business hours (multiple workflows at 9 AM, 2 PM, etc.).

Recommendation:

• Review actual execution patterns for resource utilization
• Consider spreading schedules more evenly to reduce peak-time contention

---

Methodology

Data Collection

• Source: 130 .lock.yml files in .github/workflows/
• Tools: Bash scripts with YAML parsing via grep, awk, and text processing
• Analysis Date: 2026-01-03
• Repository: githubnext/gh-aw

Analysis Scripts

All analysis scripts stored in /tmp/gh-aw/cache-memory/scripts/:

• full_analysis.sh - Comprehensive data extraction
• Historical data saved to /tmp/gh-aw/cache-memory/history/2026-01-03-analysis.json

Data Quality

• File Coverage: 100% (all 130 lock files analyzed)
• Parse Success: ~98% (2 workflows had minor parsing variations)
• Accuracy: Direct file system measurements for sizes, pattern-based extraction for structure

---

Workflow Run: §20678821918

Analysis generated on 2026-01-03 by Lockfile Statistics Analysis Agent

AI generated by Lockfile Statistics Analysis Agent