GitHub/ai-agent

13 posts

github

Write your first prompt with the GitHub Copilot app (opens in new tab)

Starting with GitHub Copilot does not require a perfect prompt or specialized syntax. The article recommends connecting Copilot to a repository or local folder, describing a task in plain English, and refining the request interactively. Users can gradually adjust the AI model, input method, and session settings as their needs become more complex. ## Start with Project Context - Connect an agent session to: - An existing GitHub repository - A local folder on your computer - Selecting a project gives Copilot access to the code and files needed for the task. - Once the project is connected, you can submit a prompt. ## Describe Tasks in Plain English - Prompts only need to explain the desired outcome. - Example: `Add a most-funded sort option to the games list.` - Copilot can inspect the codebase and identify relevant files. - If the result is incomplete or incorrect, provide more details and ask for revisions. - Prompting is iterative, so the initial request does not need to include every requirement. ## Select an Appropriate AI Model - The app supports multiple AI models with different strengths. - More capable reasoning models may help with complex tasks, while simpler models can be faster for straightforward changes. - Beginners can use the default model without understanding every model difference. - Models can be switched later if the task becomes more demanding or the initial result is unsatisfactory. ## Use Voice Input - Built-in voice input lets users describe tasks verbally. - Speech is converted into editable text before submission. - This can be useful for explaining lengthy or complicated ideas more naturally. ## Customize Agents and Sessions - Session settings allow users to select different agents for different types of work. - Remote control enables access to a session through the web. - Users can start work locally, leave their computer, and resume the same session from another device. - These options are available when needed but are not required for a first task. ## Start Small and Iterate - Begin with a modest change in a familiar project. - Review Copilot’s work and refine the prompt as necessary. - Experiment with different models or session configurations only when the task requires them. The practical recommendation is to choose a project, describe one small task in ordinary language, and begin. Experience with iterative prompting will make model selection and other Copilot settings easier to use over time.

github

From coder to orchestrator: How agents shift the role of a developer (opens in new tab)

AI agents can generate impressive one-prompt demos, but reliable software delivery requires more than isolated outputs. Developers increasingly need to design workflows that define how code is proposed, tested, reviewed, and shipped. The article argues that this shifts developers from primarily writing code to orchestrating agents within controlled, repeatable systems. ## From One-Off Prompts to Reliable Workflows - A single prompt can quickly produce a demo, such as a simple game. - Production development requires repeatable delivery with: - Appropriate context - Validation and testing - Security controls - Review processes - Clear permissions and handoffs - GitHub Copilot is presented as a control plane for connecting these parts. ## An Agentic Development Flow - Familiar repository events can trigger agent work, including: - Adding a label to an issue - Running a scheduled workflow - Starting a GitHub Actions process - The agent’s changes are captured in a pull request. - Deterministic checks then validate the work through: - Linting - Tests - Security scans - Build verification - CODEOWNERS, required reviews, and branch protection rules control what can be merged. - Agents handle ambiguous, context-heavy tasks, while predictable automation provides the safety boundary. - Developers decide: - What agents can access - How tasks are scoped - Where workflows hand off - When human judgment is required ## GitHub’s Implementation Options - Copilot cloud agent workflows support event-driven automations. - Copilot CLI can run AI-powered steps inside GitHub Actions. - Model Context Protocol (MCP) can extend agents with additional tools and external context. - These options represent different stages of building an agent-enabled development workflow. ## Starting Small - Teams should begin with one bounded, low-risk workflow. - Suitable examples include: - Issue triage - Synchronizing documentation and tests - Routine maintenance updates - The recommended approach is to integrate Copilot into existing development infrastructure rather than redesigning everything at once. Developers should treat AI agents as components within an engineered delivery system, not as replacements for that system. Start with a limited workflow, surround agent output with automated checks and review controls, and gradually expand as the process proves reliable.

github

The harness is all you need (mostly) (opens in new tab)

The post argues that effective AI-assisted development depends less on discovering elaborate prompts, tools, or configurations and more on learning the underlying agent harness. A simple workflow—choose a consistent tool, grant agents autonomy in a safe environment, and prototype before implementing—can produce major productivity gains. The author concludes that the harness is “all you need,” with only a few practical habits required. ## Choose a Tool and Learn the Harness - GitHub Copilot is available through the CLI, Copilot app, VS Code, Visual Studio, JetBrains, and other environments. - Although interfaces differ, these tools increasingly share the same underlying harness and workflow. - Beginners may benefit from starting with the CLI because its text-based interface exposes the agent’s behavior directly. - Learning the harness once makes it easier to work across different Copilot environments. ## Enable Autonomous Agent Operation Safely - “YOLO mode,” also called `/allow-all` or “Allow All,” lets the agent execute commands without requesting approval each time. - Repeated approval prompts slow development and encourage users to approve actions without reading them. - Agents should be given autonomy, but unrestricted execution is risky on local or production systems. - Use isolated environments such as GitHub Codespaces or development containers, especially when working with private organizational data. ## Prototype Before Implementing - AI makes it inexpensive to explore multiple designs before committing to an implementation. - For a date picker, the author recommends generating many HTML mockups at once—for example, 20 variations—to compare layouts and interaction models. - Reviewing prototypes can reveal ideas that are difficult to anticipate from text alone, such as navigating from year to month to day. - Visual and tangible representations help people understand complex concepts faster than dense descriptions. ## Use Visual Models for Non-Visual Work - Prototyping is also useful for backend tasks and API design. - For an analytics-download endpoint, the author suggests asking the agent to create several visual implementation options. - Mermaid diagrams can map out alternatives directly in Markdown. - Exploring these options early exposes requirements and trade-offs, reducing rework and wasted tokens. ## Keep the Model and Reasoning Settings Consistent - The author recommends using a medium-sized model with medium reasoning for most tasks. - Keep the same model and reasoning level throughout a feature, bug fix, or enhancement. - Consistency allows previous conversations to remain cached, reducing token costs on later requests. The practical recommendation is to focus less on collecting AI tools and clever prompts and more on mastering the agent workflow: give it controlled autonomy, prototype alternatives early, and maintain a consistent working context.

github

GitHub Copilot app for Beginners: Getting started (opens in new tab)

The GitHub Copilot app is designed as a development workspace rather than a single AI chat window. It connects agent sessions to projects, supports parallel tasks, provides an interactive browser canvas for UI work, and helps manage pull requests through Agent Merge. Together, these features aim to support the full workflow from exploration to shipping. ## Project-Based Agent Sessions - Each session is connected to a specific project and its repository context. - Projects can be selected from GitHub or added from a local machine. - Copilot can inspect the codebase, identify relevant files, implement changes, and run tests. - This reduces the setup required before beginning a development task. ## Managing Multiple Work Threads - Users can create separate sessions for different tasks without interrupting ongoing work. - **Quick Chat** provides a lightweight way to: - Ask questions about Copilot or the codebase - Explore implementation options - Investigate unfamiliar parts of an application - Gather context before making changes - Returning to an existing session preserves its history and allows work to continue from where it stopped. ## Interactive UI Work with Canvas - The app includes a browser canvas for previewing applications alongside the AI conversation. - Canvas can be created with the `/create-canvas` slash command. - **Enable Canvas Dev Mode** and **Pick & Polish** allow users to select page elements directly and use them as context for refinement requests. - This supports an iterative workflow in which developers can inspect the visual result, identify problems, and ask Copilot to adjust specific UI elements. ## Pull Request Assistance with Agent Merge - **Agent Merge** extends Copilot’s role beyond implementation into code review and delivery. - It can be enabled from a pull request’s options in the Copilot app. - Developers choose which actions it may perform, including: - Addressing review feedback - Helping resolve CI failures - Handling merge conflicts - Agent Merge monitors the pull request while checks and reviews are in progress, preparing it for merge once requirements are satisfied. The Copilot app is intended to centralize development activities in one workspace: start with a project, separate work into focused sessions, visually refine applications through canvas, and use Agent Merge to help complete the pull request process. Developers can learn the workflow by applying it to an existing backlog task.

github

How to build interactive experiences with canvases (opens in new tab)

Canvases extend GitHub Copilot beyond text-based conversations by providing shared, interactive workspaces where developers and agents can visualize information and take action together. They are useful for tasks such as triaging issues, exploring code architecture, managing worktrees, and searching organizational knowledge. The article concludes that canvases make AI workflows more engaging, practical, and easier to iterate on. ## How canvases work - Canvas extensions are interactive surfaces within the GitHub Copilot app. - Agents can update the canvas while users interact through clicks, edits, swipes, and other controls. - User actions may be sent back to the agent or handled locally. - Developers create one by running `/create-canvas` in a Copilot agent session and describing the desired interface and capabilities. - Canvases can evolve through follow-up prompts that add features or refine existing behavior. ## Visual issue triage - A card-based interface displays GitHub Issues one at a time. - Users swipe right to ship an issue or left to reject it. - The canvas updates immediately, organizing issues into decision-based categories. - This replaces a slower, text-heavy review process with direct visual interaction. ## Interactive codebase diagrams - A generated diagram represents components of a project as connected nodes. - Users can hover over, drag, and filter elements to explore relationships and architectural layers. - The interface turns static codebase documentation into an explorable model. ## Managing sessions and worktrees - A canvas can display active GitHub Copilot sessions and their associated Git worktrees. - It distinguishes active, stale, and orphaned worktrees. - Cleanup actions are available directly from the interface, reducing manual maintenance. ## Improving agent prompts - The prompt coach reviews previous agent interactions. - It identifies issues such as unclear context, spelling mistakes, and syntax problems. - It suggests ways to make prompts more precise and improve future agent results. ## Finding organizational knowledge - A knowledge finder can search sources such as Slack, Teams, email, and documentation. - It identifies people connected to a file or topic. - Results explain both who has relevant context and where that connection was found, making it easier to locate the right expert. ## Getting started Canvases are best suited to workflows where visual understanding and direct manipulation are more effective than sequential prompts. Developers can try them in the GitHub Copilot app by using `/create-canvas`, then iterating with the agent to build a workspace tailored to their task.

github

Automating cross-repo documentation with GitHub Agentic Workflows (opens in new tab)

The Aspire team used GitHub Agentic Workflows to automate documentation across its product and documentation repositories. For versions 13.3 and 13.4, the system produced 82 documentation pull requests, typically within 44.8 hours of the corresponding product change, with review from the engineer who shipped the feature. The approach combines AI-generated drafts with deterministic branch selection and tightly controlled write permissions. ## The Cross-Repository Documentation Problem - Product code lives in `microsoft/aspire`, while documentation lives in `microsoft/aspire.dev`. - The old process depended on writers discovering changes weeks later and reconstructing intent from closed pull requests. - Engineers often had limited context by the time clarification was requested. - Broad repository tokens were unacceptable, making secure cross-repository automation difficult. ## How GitHub Agentic Workflows Work - Workflows are authored as Markdown files with YAML-style frontmatter and natural-language instructions. - A compiler generates a standard GitHub Actions `.lock.yml` workflow. - An agent analyzes repository data and produces proposed actions as JSON rather than writing directly to GitHub. - A separate “safe-outputs” handler executes only explicitly permitted actions through a narrowly scoped GitHub App. - This separation provides AI flexibility while preserving security controls and auditability. ## The Automated Documentation Pipeline - The `pr-docs-check.md` workflow runs when a pull request is merged into `main` or a `release/*` branch. - A deterministic Bash script resolves the documentation target branch before the agent runs: - Product pull request milestone, such as `13.4`, maps to `release/13.4`. - Linked issue milestones are checked next. - The pull request’s base branch is used if it matches a release pattern. - Otherwise, documentation targets `main`. - The agent: - Reviews the product diff and linked issues. - Determines whether documentation is necessary. - Checks out `microsoft/aspire.dev`. - Writes documentation using the project’s existing writing conventions and Starlight/MDX components. - The workflow creates a draft documentation pull request with: - A `[docs]` title prefix. - The `docs-from-code` label. - A restricted base branch. - The documentation repository as the target. - The subject-matter expert who reviewed the original product pull request as reviewer. - A comment containing the documentation pull request link is posted back to the source pull request, while older workflow comments are minimized on reruns. ## Security Through Safe Outputs - The agent receives constrained GitHub tools and read access. - Repository access is limited through allowed repositories and a dedicated GitHub App. - Actions must use pinned, integrity-checked components through `min-integrity: approved`. - Write operations are restricted to declared safe outputs, such as creating pull requests. - Documentation changes remain drafts and are never auto-merged. ## Results and Broader Fit - The process eliminated the need for additional staff or major process training. - Documentation drafts arrive shortly after the related code is merged, while the implementation context is still fresh. - The workflow preserves human review by routing drafts to the engineer or SME who approved the feature. - Both the automation documentation and `aspire.dev` use Astro and Starlight, making the tooling and publishing environment closely aligned. The practical recommendation is to use agentic automation for drafting and routing documentation, but keep branch resolution, permissions, and final review deterministic and human-controlled. This provides much of the speed of autonomous workflows without granting an AI agent unrestricted repository write access.

github

How we built an internal data analytics agent (opens in new tab)

Qubot is GitHub’s internal, Copilot-powered analytics agent, designed to make warehouse data accessible without requiring an analyst. Employees ask natural-language questions through Slack, VS Code, or the Copilot CLI, while Qubot uses curated context and selects between Kusto and Trino to produce answers. GitHub’s experience shows that structured context is central to improving both accuracy and response speed. ## The Problem Qubot Addresses - Product teams often struggle to identify the right data model, grain, filters, and query. - Limited analyst availability leaves many teams to investigate telemetry independently. - Qubot targets exploratory questions rather than replacing dashboards or formal reporting. - It enables employees to investigate unfamiliar datasets with minimal setup and maintenance. ## Multiple Ways to Ask Questions - **Slack:** Users ask questions in a shared channel, receive answers in threads, and collaborate on follow-up questions. - Each result is saved as a Markdown report in a pull request, allowing users to refine queries or reuse them in dashboards. - **VS Code and Copilot CLI:** Qubot is installed as a plugin and operates alongside other agents, skills, and tools. - Offering both zero-configuration and developer-focused interfaces increased adoption among different user groups. ## A Federated Context Layer Qubot’s context is tailored to GitHub’s warehouse layers: - **Bronze:** Product teams provide telemetry schemas and metadata for raw events. - **Silver:** Data teams maintain query examples, usage guidance, and required filters for conformed data. - **Gold:** Dataset owners contribute business rules and metric definitions. - ETL pipelines add derived metadata and other signals automatically. - Context is fetched at runtime through the GitHub MCP Server. A dedicated context agent standardizes contributions from different teams. It ingests Markdown documentation and repository references, then organizes and normalizes them into a structure that Qubot can use effectively. ## Evaluation Before Deployment Every change to Qubot’s instructions or context layer is tested through an offline evaluation framework. - Test cases contain prompts, expected answers, ground-truth SQL, domains, and difficulty levels. - Automated orchestration launches multiple parallel agent trials using `gh agent-task create`. - Results are saved as JSON and aggregated by completion rate, accuracy, and duration. - Teams compare configurations and detect regressions before releasing changes. ## Choosing Between Kusto and Trino Qubot connects to both query engines through MCP servers: - **Kusto** is used for fast exploration of recent event data. - **Trino** handles complex joins and deeper historical analysis. - Qubot defaults to Kusto and switches to Trino when the question requires more advanced or historical querying. - This hides query-engine selection from users. ## Adoption and Lessons Learned - Hundreds of GitHub employees have run thousands of queries through Qubot. - Routine questions in analytics support channels declined as teams gained more autonomy. - The agent helped employees who previously avoided the warehouse access data for decision-making. - GitHub found that well-structured, carefully maintained context improved accuracy and made Qubot approximately three times faster at finding the right answer. The main recommendation is to treat analytics context as a maintained engineering asset. A capable agent depends not only on model intelligence, but also on accurate metadata, documented business rules, evaluation-driven iteration, and interfaces that fit users’ existing workflows.

github

GitHub Copilot CLI combines model families for a second opinion (opens in new tab)

GitHub Copilot CLI’s experimental Rubber Duck feature adds an independent reviewer from a different AI model family to catch mistakes before they compound. When Claude models orchestrate a task, GPT-5.4 reviews plans, implementations, and tests at key checkpoints. On SWE-Bench Pro, Claude Sonnet 4.6 with Rubber Duck closed 74.7% of the performance gap with Claude Opus 4.6 alone, particularly on complex, multi-file tasks. ## The Problem with Self-Review - Coding agents typically assess a task, plan, implement, test, and iterate. - Early assumptions can create downstream dependencies and make small mistakes expensive to fix. - Self-reflection helps, but a model reviewing its own work may retain the same training biases and blind spots. ## Cross-Family Review with Rubber Duck - Rubber Duck is a focused review agent powered by a complementary model family. - Claude orchestrators currently use GPT-5.4 as the reviewer. - It produces a short list of high-value concerns, including: - Missed details - Questionable assumptions - Architectural risks - Relevant edge cases ## Evaluation Results - On SWE-Bench Pro, Sonnet 4.6 plus Rubber Duck approached the resolution rate of Opus 4.6 running alone. - Benefits were strongest for problems involving at least three files and 70 or more steps. - Sonnet plus Rubber Duck scored: - 3.8% above the Sonnet baseline on difficult tasks - 4.8% higher on the hardest tasks across three trials - Examples included detecting: - A scheduler that would start and immediately exit - A loop overwriting one dictionary key and dropping Solr facet categories - Cross-file Redis references that would silently break email confirmation flows ## When Reviews Happen Rubber Duck can be invoked automatically, reactively, or on request: - After a plan is drafted, to prevent flawed decisions from spreading. - After complex implementation work, to identify edge cases. - After tests are written but before they run, to expose coverage gaps or weak assertions. - When the primary agent is stuck or repeating an unproductive loop. - Any time the user asks Copilot to critique its work. Copilot incorporates the feedback and explains what changed. Reviews are intentionally infrequent and targeted at checkpoints where they provide the most value. ## Availability and Use Cases - Rubber Duck is available in Copilot CLI’s experimental mode through `/experimental`. - It works with Claude Opus, Sonnet, and Haiku as orchestrator models, provided the user has GPT-5.4 access. - It is especially suited to: - Complex refactors and architectural changes - High-stakes coding tasks - Test coverage review - Getting a second opinion before committing to a plan Rubber Duck is a practical way to reduce model-specific blind spots by combining different AI families. Developers can enable it experimentally in Copilot CLI and use automatic or on-demand critiques for difficult work.

github

Agent-driven development in Copilot Applied Science (opens in new tab)

The post describes how Tyler McGoffin used GitHub Copilot to automate the intellectual work of analyzing coding-agent evaluation trajectories. This led to `eval-agents`, a tool designed to let researchers create, share, and run specialized agents. By making coding agents the primary contributors, the team rapidly added 11 agents, four skills, and workflow support while learning new approaches to prompting, architecture, and collaboration. ## The Motivation: Automating Evaluation Analysis - McGoffin analyzes coding-agent performance using benchmarks such as TerminalBench2 and SWEBench-Pro. - Each benchmark task produces a trajectory: a large JSON record of the agent’s thoughts and actions. - Reviewing hundreds or thousands of trajectories can involve hundreds of thousands of lines of data. - Copilot initially helped identify patterns, reducing the amount of material requiring manual inspection from hundreds of thousands of lines to a few hundred. - The repetitive nature of this process inspired `eval-agents`, which automates parts of the analysis itself. ## Project Goals The project was designed around three objectives: - Make agents easy for others to share and use. - Make authoring new agents straightforward. - Make coding agents the primary mechanism for contributing to the project. The third goal had the greatest architectural impact. Using Copilot to build the tool also made the repository easier for teammates to understand, extend, and collaborate on. ## An Agent-First Development Setup McGoffin’s development environment consisted of: - Copilot CLI as the coding agent. - Claude Opus 4.6 as the model. - VS Code as the IDE. - The Copilot SDK for creating agents, registering tools and skills, and accessing existing MCP servers. This setup allowed the project to reuse Copilot’s existing agent infrastructure instead of implementing those capabilities from scratch. ## Prompting Strategies - Agents perform best when treated like capable engineers rather than simple code generators. - Effective prompts are conversational, detailed, and explicit about assumptions. - Planning mode should be used before implementation mode, especially for complex tasks. - McGoffin used stream-of-consciousness descriptions to explain problems and collaborate with Copilot on possible solutions. - For example, a discussion about preventing agents from weakening regression tests led to protected test areas and human-controlled contract-test-like guardrails. - The broader lesson is that agents benefit from many of the same practices as human engineers: context, dialogue, planning, and clear constraints. ## Architectural Strategies An agent-first codebase makes maintainability work especially valuable: - Refactoring names and file structures improves the repository’s understandability. - Documentation gives agents the context needed to implement features consistently. - Additional tests expose and prevent recurring mistakes. - Removing dead code helps keep agents from copying outdated or irrelevant patterns. - Work that was traditionally postponed—cleanup, documentation, and test improvements—becomes foundational when agents are responsible for much of the implementation. ## Rapid Team Collaboration Applying these principles enabled substantial development in a short period: - Five people contributed to the project for the first time. - The team created 11 agents and four skills. - They introduced eval-agent workflows for structured streams of scientific reasoning. - In under three days, the changes amounted to approximately 28,858 added and 2,884 removed lines across 345 files. ## Practical Recommendation Teams adopting agent-driven development should invest first in clear architecture, documentation, tests, and conversational planning practices. Agents become substantially more effective when the repository provides strong context and guardrails, allowing developers to focus less on repetitive implementation and more on directing, reviewing, and improving the overall system.

github

How Squad runs coordinated AI agents inside your repository (opens in new tab)

Squad is an open-source GitHub Copilot project that places a preconfigured team of AI agents directly inside a repository. Rather than relying on a single chatbot or complex orchestration infrastructure, it coordinates specialized agents for design, implementation, testing, documentation, and review. Its core argument is that repository-native, versioned context makes multi-agent development more accessible, inspectable, and resilient. ## Coordinating Specialized Agents - Install Squad with `npm install -g @bradygaster/squad-cli`, then run `squad init` in a repository. - The setup creates roles such as lead, frontend developer, backend developer, tester, and documentation specialist. - A coordinator interprets natural-language requests, loads repository context, and assigns work to specialists. - Agents can work in parallel, create files and branches, write tests, and open pull requests. - They use shared decisions and project history rather than requiring every detail to be repeated in prompts. - Testing and review happen within the workflow: - Testers evaluate implementations and reject failing code. - A rejected author is prevented from revising its own work. - Another agent must address the problems, providing a more independent review. - Developers still answer questions, correct assumptions, and review and merge pull requests; Squad is collaborative orchestration rather than full autonomy. ## Repository-Based Shared Memory - Squad uses a “drop-box” model instead of depending on live chat synchronization or complex vector databases. - Architectural decisions, library choices, and conventions are appended to a versioned `decisions.md` file. - This creates: - Persistent shared knowledge - An understandable audit trail - Recovery after disconnects or restarts - Memory that can be reviewed and changed like code ## Replicating Context Across Agents - The coordinator remains a thin router instead of attempting to manage all implementation work. - Each specialist runs in its own inference call with an independent context window. - This replicates relevant repository context across agents rather than splitting one limited context among multiple roles. - Parallel, independent contexts reduce the risk that project-management instructions and other agents’ reasoning crowd out the actual coding task. - Supported models may provide context windows of up to 200,000 tokens. ## Versioned Agent Identities and History - Each agent’s behavior is primarily defined by repository files: - A charter describing its role and responsibilities - A history recording previous work - Shared team decisions - These files live in `.squad/` alongside the application code. - Cloning a repository also restores the team’s accumulated knowledge, making the agents effectively pre-onboarded. - Keeping memory in plain text makes it inspectable, versioned, and independent of hidden model state. ## Lowering the Barrier to Multi-Agent Development Squad’s main goal is to make agentic workflows practical without requiring users to build orchestration layers, configure databases, or master advanced prompt engineering. Its repository-native design favors simple setup, transparent memory, independent review, and recoverable project context. Developers interested in this approach can install Squad and experiment with it directly in the project repository.

github

The era of “AI as text” is over. Execution is the new interface. (opens in new tab)

The post argues that AI is moving beyond text-based question-and-answer interactions toward embedded execution. The GitHub Copilot SDK lets applications use Copilot’s planning, tool use, file modification, command execution, and error recovery capabilities directly. This enables teams to build adaptable AI workflows without creating their own orchestration infrastructure. ## Delegating Multi-Step Work to Agents - Applications can express intent and constraints instead of hard-coding every workflow step. - For a task such as “Prepare this repository for release,” an agent can: - Explore the repository - Plan the necessary work - Modify files - Run commands - Recover and adapt when failures occur - This approach is more flexible than scripts, which become brittle when workflows depend on changing context or unexpected errors. - Teams can use agentic execution while maintaining defined boundaries and observability. ## Using Structured Runtime Context - Relying on prompts to contain system logic makes workflows difficult to test, maintain, and evolve. - The Copilot SDK supports structured, composable context through: - Domain-specific tools and agent skills - Model Context Protocol (MCP) - Runtime retrieval of relevant data - Agents can directly access systems such as: - Service ownership records - Historical decisions - Dependency graphs - Internal APIs - Permissioned tools and real-time data provide more reliable grounding than embedding organizational knowledge in prompts. ## Embedding Agents Beyond the IDE - Agentic capabilities can be integrated into: - Desktop applications - Internal operational tools - Background services - SaaS products - Event-driven systems - Applications can invoke Copilot in response to events such as file changes, deployments, or user actions. - Execution happens within the product itself rather than in a separate IDE or terminal interface. - This turns AI from an auxiliary developer tool into application infrastructure available wherever the software operates. ## Execution as a New Interface - Agentic workflows are programmable planning-and-execution loops that: - Integrate with real systems - Operate under constraints - Adapt during runtime - Use tools to complete tasks - The Copilot SDK provides this execution layer so teams can focus on defining outcomes instead of rebuilding orchestration systems. The practical recommendation is to treat AI as an executable application capability rather than merely a text interface. Teams can start by identifying multi-step workflows or event-driven tasks where structured tools, runtime context, and adaptive execution would provide more value than fixed scripts.

github

Automate repository tasks with GitHub Agentic Workflows (opens in new tab)

GitHub Agentic Workflows bring coding agents into GitHub Actions, allowing developers to describe repository tasks in Markdown instead of complex YAML. They can automate issue triage, documentation, testing, code cleanup, CI investigation, and reporting while preserving human oversight through permissions, sandboxing, logging, and review. The post presents the technology, now in technical preview, as an extension of CI/CD rather than a replacement for deterministic build and release pipelines. ## Markdown-Defined Repository Automation - Developers describe desired outcomes in plain Markdown and add the workflow to a repository. - The workflow runs in GitHub Actions using configurable coding agents such as: - GitHub Copilot CLI - Claude Code - OpenAI Codex - Because workflows operate within GitHub Actions, they benefit from repository context, audit logs, permission controls, and sandboxed execution. ## Examples of Continuous AI GitHub describes these workflows as “Continuous AI”: AI-powered automation integrated throughout the software development lifecycle. - **Issue triage:** Summarize, label, and route new issues. - **Documentation maintenance:** Update READMEs and documentation after code changes. - **Code simplification:** Find opportunities for improvement and open pull requests. - **Test improvement:** Evaluate coverage and add valuable tests. - **Quality hygiene:** Investigate CI failures and suggest targeted fixes. - **Reporting:** Produce recurring reports on repository health, activity, and trends. These tasks are difficult to implement with traditional deterministic YAML workflows because they require interpretation, judgment, and code changes. ## Relationship to CI/CD - Agentic workflows are intended to augment, not replace, existing CI/CD systems. - Traditional pipelines remain responsible for deterministic builds, tests, and releases. - Agentic workflows handle higher-level tasks involving analysis, recommendations, and repository maintenance. - GitHub Actions provides the infrastructure needed for controlled execution and observability. ## Guardrails and Human Control - Security is presented as a core design requirement, particularly against unintended behavior and prompt injection. - Workflows run with read-only permissions by default. - Write operations require explicit approval through “safe outputs,” which are designed to make changes pre-approved and reviewable. - The overall approach emphasizes inspectability, defined boundaries, and human review rather than unrestricted autonomous changes. ## Adoption Across Teams - GitHub Next reports using workflows to replace repetitive chores and assemble useful information for developers. - Home Assistant uses them to analyze large numbers of issues and identify important trends. - The Cloud Native Computing Foundation applies them to documentation automation and organizational reporting. - Carvana uses them for engineering work spanning multiple repositories. GitHub Agentic Workflows are best viewed as a controlled way to add AI judgment to repository operations. Teams should begin with focused, reviewable maintenance tasks and expand usage as they gain confidence in the workflows’ behavior and safeguards.

github

Continuous AI in practice: What developers can automate today with agentic CI (opens in new tab)

Continuous AI extends CI into software-engineering tasks that require judgment, context, and interpretation rather than deterministic rules. It uses continuously running agents guided by natural-language instructions to review repositories, identify issues, and produce reviewable artifacts such as patches, issues, or reports. GitHub’s central argument is that AI should complement—not replace—traditional CI, while operating within explicit permissions and developer oversight. ## Why CI Isn’t Enough - CI is effective for binary, rule-based checks: - Tests pass or fail. - Builds succeed or fail. - Linters detect defined violations. - Many important engineering tasks depend on intent and context, including: - Finding discrepancies between documentation and implementation. - Detecting confusing accessibility text that passes linting. - Identifying behavioral changes caused by dependency updates. - Spotting subtle performance regressions, such as compiling a regular expression inside a loop. - Recognizing UI regressions that only appear during interaction. - GitHub describes this as a shift from AI-generated code toward AI handling cognitively demanding maintenance work. ## What Continuous AI Means - Continuous AI is a pattern, not a replacement for CI: - **Natural-language rules + agentic reasoning, executed continuously inside a repository.** - Developers describe expectations in natural language, especially when those expectations are difficult to encode with schemas, heuristics, or YAML. - Example workflows include: - Comparing documented behavior with implementation and proposing fixes. - Producing weekly reports on project activity, bug trends, and code churn. - Detecting performance regressions in critical paths. - Finding semantic regressions in user flows. - Workflows are refined collaboratively with agents by adding intent, constraints, and acceptable outputs rather than being authored as a perfect single instruction. ## Guardrails and Safe Outputs - Agents operate with read-only repository access by default. - They cannot modify content, create issues, or open pull requests unless explicitly authorized. - “Safe Outputs” defines the exact artifacts an agent may produce and the constraints governing them. - Agent activity is sanitized, logged, and auditable. - The goal is to keep the potential impact predictable even when agents make mistakes or behave unexpectedly. ## Natural Language Complements YAML - Deterministic problems should remain in CI, using YAML, schemas, tests, and heuristics. - Some expectations—such as determining whether documentation and code still express the same behavior—require semantic understanding. - Natural-language instructions let agents reason about intent without forcing that intent into brittle rules. - Continuous AI therefore expands automation into judgment-heavy tasks while preserving CI as the foundation for deterministic validation. ## Developers Remain in the Loop - Agents do not make unrestricted autonomous commits. - Depending on permissions, they can produce pull requests, issues, comments, discussions, or other reviewable artifacts. - Pull requests are especially useful because they fit existing developer review and collaboration practices. - The broader vision is to delegate recurring maintenance work while allowing developers to retain judgment, taste, and final control. Continuous AI is best adopted alongside traditional CI: use conventional automation wherever rules are sufficient, and use guarded, continuously running agents for tasks involving interpretation, synthesis, and evolving intent.