Don Syme: Building Agentic Automation Around Human Collaboration

I came into computer science through formal verification, later working on programming languages and developer tools. At GitHub Next, I have been exploring how AI changes software development and collaboration. My examples are experiments and proposals, not guarantees about what every agent can do.

The pace of change is unsettling: tasks that once took large teams can now produce prototypes quickly with agents, although a prototype is not the same as a mature, reliable system. I also underestimated how useful chat would become as a way for people and AI to explore a problem together.

GitHub was built around human collaboration but now hosts increasing AI participation. This raises questions about teamwork, quality, review, deployment and whether existing structures such as merge queues and CI/CD will change.

I use a metaphor: everyone in a meeting is now a wizard who can quickly produce a prototype. Six people might produce six prototypes, but individual power does not automatically create coordination. An agent acting in a shared project can also cross agreed boundaries.

Most AI tools emphasize individual productivity. I am interested in autonomous collaborators that can work within familiar repository processes: answer questions, analyze issues, suggest improvements or help with releases while a maintainer is away, with appropriate limits.

We began calling this continuous AI in 2025: automated activity responds to changes or events, much as continuous integration and deployment do. The additional category covers tasks that require judgment, while retaining deterministic CI/CD as an important trust boundary.

For example, a large enterprise may need to roll out vulnerability fixes or dependency upgrades across thousands of repositories. Those changes require judgment and coordination. A general automation system could support many such activities rather than requiring a separate tool for every task.

GitHub Actions is interesting because repository permissions can grant bounded access to compute, networking and storage. Adding AI to that environment can combine automation with an existing record of runs, though permission boundaries and costs still require careful design.

Continuous fault analysis is one possible application: collect service failures and telemetry, investigate a cluster of problems and prepare a proposed fix before an on-call engineer reaches the computer. This is a workflow vision; a proposed fix still needs validation.

For maintainers, the goal is to wake up to useful work aligned with the direction they set: perhaps a performance suggestion, an analysis of a feature request or a maintenance improvement. The maintainer should define the automation, decide what is valuable and control its cost.

Because the workflows repeat and leave records, their definitions can be reviewed and improved. I describe examining past runs for failures and converting reliable portions of reasoning into scripts. I also suggest comparing models on identical tasks, while noting that the proposed exam-style testing was not yet implemented.

A shared ledger matters. In my examples, GitHub issues and pull requests provide a familiar place where humans and agents can see and discuss work. Collaboration through that ledger has limitations, but it builds on processes many teams already use.

GitHub Agentic Workflows is one implementation. A maintainer checks in a Markdown workflow and runs a compilation and checking step that creates an Actions workflow. The Markdown describes triggers, permissions, allowed outputs and the task for the agent.

Issue triage is an example: when an issue is opened or reopened, the workflow can gather context, assess completeness and propose or apply configured actions. The maintainer chooses what the workflow is supposed to do.

In the architecture I describe, the agentic step has no direct secret access, network access is controlled, and outputs are limited to declared channels. A weekly researcher might be allowed to create one issue rather than freely editing the repository. These are design controls, not proof that all risks disappear.

Prompt injection and data leakage are two major concerns. The workflow restricts which outside issues it sees, and public-repository automation should not be given private data or tokens it could expose in logs. The described setup uses sandboxing, minimized permissions, restricted outputs and human review before merging pull requests.

My colleague Peli de Halleux maintains a collection of specialized workflows, an “agent zoo.” One example examines existing Go dependencies for better ways to use them and remove redundant code. He reported 58 merged pull requests from 74 proposals for that workflow; that is a specific case, not a general success rate.

A useful pattern separates research from changes: an agent writes a report, a human reviews it, and a later step turns a selected idea into a pull request. The issue and pull-request history provides an audit trail for following the chain.

Other possible workflows include improving test coverage and maintaining performance benchmarks. My hope is to make recurring performance work sustainable instead of relying on occasional heroic efforts. More tests or benchmark activity alone do not guarantee better quality.

I used Repo Assist on relatively dormant F# repositories. In one example it analyzed old issues, suggested closures or fixes and helped lead to new releases; I reviewed the suggestions. Results vary with backlog size and maintainer engagement, so the example is not a controlled study.

Guardrails can make unattended automation more useful: if the system remains within well-designed boundaries, a maintainer can let it run with less concern. Those boundaries need to be tested and maintained, not merely assumed.

I also experimented with Lean Squad, a recurring workflow that identifies targets, extracts informal specifications, writes formal specifications, compares models with code and critiques its work. The experiment asks whether this form of automation can produce useful verification work; its value depends on the setting and independent review.

I describe repositories as human–agent knowledge factories, then offer a softer metaphor: software farms. The important question is end-to-end flow. Making each individual produce more can worsen a bottleneck if the rest of the system cannot absorb the output.

Design questions include where the automation runs, its ledger and quality gates, whether humans can intervene, who authorizes actions, resistance to outside instructions, cost limits and audit history. I describe centrally controlled automation repositories with bounded access to other repositories as one possible pattern.