Agentic AI Testing with GitHub Copilot Agents, MCP, and Playwright

Modern AI-assisted testing can be divided into two major approaches: Generative AI testing and Agentic AI testing. Understanding the difference — and how GitHub Copilot Agents, MCP, and Playwright MCP fit together — is becoming a core skill for SDETs and Test Architects.

1. Overview: Generative AI Testing

Generative AI helps an SDET create testing assets. Examples include:

Generate test cases from acceptance criteria
Generate Playwright tests
Generate test data
Generate API tests
Generate SQL queries
Create Page Objects
Analyze failures
Generate test documentation

Example prompt:

text

Read the Login acceptance criteria.

Generate Playwright TypeScript tests covering:
- valid login
- invalid password
- missing username
- missing password
- locked user

The AI generates the requested artifacts, but the workflow is still primarily driven by the SDET. A simple way to remember it:

text

Generative AI
=
"Create something for me."

2. What Is Agentic AI Testing?

Agentic AI goes beyond content generation. Instead of asking AI to only generate tests, we provide a testing goal.

text

Test the Login feature against the application.

Use the acceptance criteria.

Execute the scenarios.

Verify expected vs actual behavior.

Investigate failures.

Report defects.

Now the AI may:

text

Understand Requirement
        ↓
Plan Testing
        ↓
Use Tools
        ↓
Open Application
        ↓
Execute Actions
        ↓
Observe Results
        ↓
Reason About Results
        ↓
Decide Next Action
        ↓
Verify
        ↓
Report

This creates the agentic loop:

text

GOAL
 ↓
PLAN
 ↓
ACT
 ↓
OBSERVE
 ↓
REASON
 ↓
DECIDE
 ↓
VERIFY
 ↓
REPORT

text

Agentic AI
=
"Achieve this testing goal for me."

3. Where GitHub Copilot Fits

GitHub Copilot can act as the AI agent environment. Instead of building our own AI agent application, we can create specialized GitHub Copilot Custom Agents.

Architecture:

text

SDET
 ↓
GitHub Copilot Agent
 ↓
MCP
 ↓
Playwright MCP
 ↓
Playwright
 ↓
Browser
 ↓
Application

The responsibilities are:

text

GitHub Copilot Agent
=
Reasoning + Planning + Decision Making

MCP
=
Standardized connection to tools

Playwright MCP
=
Browser tools exposed to the AI

Playwright
=
Browser automation engine

Browser
=
Actual execution environment

4. Do We Need .agent.md Files for Generative AI?

No. If you only want Copilot to generate something — Playwright tests, test cases, test data, a failure explanation, API automation, or a framework review — you can simply prompt Copilot.

Custom agent files become useful when you want a reusable specialized AI role. For example:

text

.github/
└── agents/
    ├── requirement-analyst.agent.md
    ├── test-planner.agent.md
    ├── test-executor.agent.md
    └── defect-analyst.agent.md

These agents can have different responsibilities and different tool permissions.

5. GitHub Copilot Custom Agent

A Copilot Custom Agent is usually defined as a Markdown file, for example .github/agents/test-executor.agent.md:

.github/agents/test-executor.agent.md

---
name: Test Executor
description: Executes browser test scenarios using Playwright MCP
tools:
  - read
  - search
  - execute
  - playwright/*
---

You are a Senior SDET Test Executor.

For every scenario:

1. Understand the testing goal.
2. Open the approved application.
3. Inspect the current UI.
4. Determine the next browser action.
5. Execute the action using Playwright MCP.
6. Observe the result.
7. Compare expected vs actual behavior.
8. Capture useful evidence.
9. Report PASS, FAIL, or BLOCKED.

Never report PASS without verification.

The agent now has a reusable testing role.

6. Repository-Level Copilot Instructions

A project can also contain .github/copilot-instructions.md. This file defines rules that should apply across the repository. For example:

Use TypeScript.
Prefer getByRole(), getByLabel(), and getByPlaceholder().
Use Playwright web-first assertions.
Do not use arbitrary waits.
Keep tests independent.
Never hardcode credentials.
Do not weaken assertions to make tests pass.
Use synthetic test data.

Think of it this way: copilot-instructions.md = rules everyone follows, while .agent.md = a specialized AI role.

7. What Is MCP?

MCP stands for Model Context Protocol. MCP provides a standardized way for AI agents to connect with tools and systems.

Without MCP, teams may need individual custom integrations — a custom browser integration, a custom GitHub integration, a custom Jira integration, a custom database integration. With MCP:

text

                   GitHub Copilot Agent

                           │

                           MCP

          ┌────────────────┼────────────────┐
          ↓                ↓                ↓

    Playwright MCP      GitHub Tool     Database Tool

For SDET use cases, MCP can allow the AI agent to interact with systems instead of only generating text.

8. What Is Playwright MCP?

Playwright MCP exposes browser automation capabilities to an AI agent. Conceptually, it can provide tools such as:

browser_navigate
browser_snapshot
browser_click
browser_type
browser_fill_form
browser_take_screenshot

The important part is browser_snapshot. Instead of the AI having to understand complex HTML or guess coordinates, Playwright MCP can expose structured page information. For example:

text

heading "todos"

textbox "What needs to be done?"
ref=e5

link "Active"
ref=e21

link "Completed"
ref=e22

The AI can reason that ref=e5 is the Todo input, and then use it for interaction.

9. Configuring Playwright MCP

A local VS Code project can contain .vscode/mcp.json:

.vscode/mcp.json

{
  "servers": {
    "playwright": {
      "type": "stdio",
      "command": "npx",
      "args": [
        "-y",
        "@playwright/mcp@latest",
        "--isolated"
      ]
    }
  }
}

This starts npx @playwright/mcp@latest --isolated. The --isolated option is useful for testing because the browser session starts with fresh state. This reduces accidental dependencies on old cookies, previous local storage, existing login sessions, or previous test state.

10. Basic Agentic Test Example

Suppose our application is https://demo.playwright.dev/todomvc. The requirement: AC1 — the user can add a Todo. AC2 — the Todo appears in the list. We give the Copilot agent this goal:

text

Open the Todo application.

Add:

"Learn Agentic Testing"

Verify that the Todo appears.

Report PASS or FAIL.

The agent may perform the following workflow.

Step 1 — Navigate

The agent calls browser_navigate.

Step 2 — Inspect UI

The agent calls browser_snapshot and may observe a textbox "What needs to be done?" with ref=e5.

Step 3 — Decide

The agent determines that e5 is the input field.

Step 4 — Execute

text

browser_type

ref=e5

text="Learn Agentic Testing"

submit=true

Step 5 — Observe Again

The agent calls browser_snapshot and may now see a listitem containing "Learn Agentic Testing".

Step 6 — Verify

text

Expected:
Todo appears in list.

Actual:
Learn Agentic Testing is visible.

Status:
PASS

This is agentic testing because the AI is participating in planning, tool selection, execution, observation, decision making, and verification.

11. Designing Multiple SDET Agents

For enterprise testing, separating responsibilities is cleaner than using one giant agent. Recommended structure:

text

.github/
└── agents/

    ├── qa-orchestrator.agent.md

    ├── requirement-analyst.agent.md

    ├── test-planner.agent.md

    ├── test-executor.agent.md

    ├── defect-analyst.agent.md

    └── regression-test-engineer.agent.md

Architecture:

text

                  QA Orchestrator

                        │

        ┌───────────────┼───────────────┐

        ↓               ↓               ↓

 Requirement        Test Planner      Risk Analysis
   Analyst

                        │

                        ↓

                 Test Executor

                        │

                        MCP

                        ↓

                 Playwright MCP

                        ↓

                     Browser

                        ↓

                  Application

                        ↓

                  PASS / FAIL

                        ↓

                 Defect Analyst

                        ↓

             Regression Test Engineer

                        ↓

                 Playwright Tests

12. Requirement Analyst Agent

The Requirement Analyst focuses on understanding what should be tested. Given acceptance criteria — valid user can login, invalid password displays an error, username is required, password is required — possible analysis:

text

Positive:

TC-001 Valid login


Negative:

TC-002 Invalid password

TC-003 Empty username

TC-004 Empty password


Potential Boundary Tests:

Whitespace username

Very long username


Requirement Gaps:

Locked-user behavior is not defined.

Maximum password length is not defined.

An important rule: Unknown behavior ≠ Assumed requirement. The agent should identify a requirement gap instead of inventing expected behavior.

13. Test Planner Agent

The Test Planner converts requirements into executable scenarios. Example:

text

ID:
TC-001

Title:
Valid User Login

Requirement:
AC1

Precondition:
Active test user exists.

Test Data:
Valid username/password.

Goal:
Authenticate successfully.

Expected Result:
Dashboard appears.

Priority:
Critical

Regression Candidate:
Yes

The planner should focus on what to test, not browser selectors. Bad planning: "Click #login-btn". Better planning: "Submit valid credentials and verify successful authentication." The Test Executor determines the UI implementation details.

14. Test Executor Agent

The Test Executor receives a scenario — "Verify that a valid user can log in. Expected: Dashboard is displayed." — and then:

text

Opens Application
      ↓
Inspects UI
      ↓
Finds Username
      ↓
Finds Password
      ↓
Enters Credentials
      ↓
Submits
      ↓
Observes Application
      ↓
Compares Expected vs Actual

The executor should never assume that a successful click equals a passed test. PASS requires observable verification.

15. Defect Analyst Agent

A failed automated scenario does not automatically mean an application defect. Possible classifications include:

text

                   FAILURE

                      │

       ┌──────────────┼──────────────┐

       ↓              ↓              ↓

Application       Automation      Environment
  Defect             Issue           Issue

                      │

                      ↓

               Requirement Gap

Example: expected — invalid password should display "Invalid username or password." Actual — 500 Internal Server Error. The Defect Analyst could produce:

text

Title:
Login returns Internal Server Error for invalid password

Severity:
High

Steps:
1. Open Login page.
2. Enter valid username.
3. Enter invalid password.
4. Submit Login.

Expected:
Authentication error message.

Actual:
500 Internal Server Error.

Classification:
Application Defect

16. Regression Test Engineer

Agentic testing should complement — not replace — deterministic Playwright tests. An AI agent may discover a valuable scenario. Once behavior is verified, it can be converted into a permanent test:

typescript

test('locked user sees account locked message', async ({ page }) => {

    await loginPage.login(
        lockedUser.username,
        lockedUser.password
    );

    await expect(
        loginPage.errorMessage
    ).toHaveText(
        'Account locked'
    );

});

The permanent Playwright test should remain deterministic, repeatable, version controlled, reviewable, and CI-friendly. A good architecture is:

text

Agentic Exploration

        ↓

Discover Important Behavior

        ↓

Verify Requirement

        ↓

Create Regression Test

        ↓

Code Review

        ↓

GitHub

        ↓

CI/CD

17. Why Traditional Playwright Tests Are Still Important

Traditional Playwright automation defines the expected workflow explicitly:

typescript

await page.goto('/login');

await username.fill(user);

await password.fill(password);

await loginButton.click();

await expect(dashboard).toBeVisible();

This is still ideal for stable regression testing because execution is predictable. Agentic testing is especially valuable for:

Exploratory testing
Requirement-driven testing
Unknown UI exploration
Failure investigation
Test scenario discovery
Risk-based validation
Generating regression candidates

The strongest architecture combines both: AI Reasoning + Agentic Exploration + Deterministic Playwright Automation.

18. Least-Privilege Agent Design

Not every AI agent should receive every tool. Example:

Requirement Analyst: read, search
Test Planner: read, search
Test Executor: read, search, playwright/*
Defect Analyst: read, search, playwright/*
Regression Test Engineer: read, edit, execute

This follows an important security principle: give each agent only the tools required for its responsibility.

19. Guardrails for Agentic Testing

Agents with tools can perform real actions. Enterprise implementations therefore need clear limits. Example rules:

Only test approved domains.
Never perform real financial transactions.
Never delete production data.
Never change production permissions.
Never expose credentials.
Use synthetic test data.
Do not navigate outside approved systems.
Require human approval before destructive actions.

A controlled workflow might be:

text

Agent requests action

        ↓

Risk Evaluation

   ┌────┴────┐

   ↓         ↓

Low Risk   High Risk

   ↓         ↓

Execute    Human Approval
              ↓
           Execute

20. Enterprise Agentic Testing Architecture

A more advanced organization could build:

text

                       JIRA STORY

                           ↓

                    QA ORCHESTRATOR

                           │

       ┌───────────────────┼───────────────────┐

       ↓                   ↓                   ↓

 Requirement          Risk Analysis        Test Planner
    Agent                 Agent               Agent

                           ↓

                    Execution Agent

                           │

             ┌─────────────┼─────────────┐

             ↓             ↓             ↓

       Playwright MCP    REST API      Database
             │             │             │
             └─────────────┼─────────────┘

                           ↓

                    Validation Agent

                           ↓

                     PASS / FAIL

                           ↓

                    Defect Analyst

                           ↓

                    Jira / GitHub

                           ↓

                Regression Test Agent

                           ↓

                     GitHub PR

                           ↓

                        CI/CD

Now the system can validate UI, API, database, requirements, and the business workflow together.

21. Example Enterprise Workflow

Suppose the requirement is: "As a customer, I want to purchase a subscription so I can access premium features." Acceptance criteria:

AC1: Customer can purchase subscription.
AC2: Payment API returns successful transaction.
AC3: Subscription record is stored in database.
AC4: Dashboard shows active subscription.

Agentic workflow:

text

Read Requirement
       ↓
Analyze AC
       ↓
Create UI/API/DB Test Plan
       ↓
Open Application
       ↓
Perform UI Workflow
       ↓
Capture Transaction ID
       ↓
Validate API
       ↓
Query Database
       ↓
Validate Subscription Record
       ↓
Return to UI
       ↓
Verify Dashboard
       ↓
PASS / FAIL
       ↓
Investigate Failure
       ↓
Generate Report

This represents AI-enabled Quality Engineering rather than simple AI-assisted test generation.

22. Recommended Project Structure

A practical GitHub Copilot Agent + Playwright project could look like:

text

agentic-playwright-testing/

├── .github/
│   │
│   ├── copilot-instructions.md
│   │
│   └── agents/
│       ├── qa-orchestrator.agent.md
│       ├── requirement-analyst.agent.md
│       ├── test-planner.agent.md
│       ├── test-executor.agent.md
│       ├── defect-analyst.agent.md
│       └── regression-test-engineer.agent.md
│
├── .vscode/
│   └── mcp.json
│
├── requirements/
│   └── login.md
│
├── prompts/
│   └── run-agentic-test.md
│
├── tests/
│   ├── ui/
│   └── api/
│
├── evidence/
│
├── reports/
│
├── playwright.config.ts
│
├── package.json
│
└── tsconfig.json

23. Example Orchestrator Prompt

Select your QA Orchestrator agent and provide:

text

Test requirements/login.md end to end.

1. Analyze every acceptance criterion.
2. Identify requirement gaps.
3. Create risk-based test scenarios.
4. Execute the appropriate scenarios using Playwright MCP.
5. Verify each expected result with observable evidence.
6. Report PASS, FAIL, or BLOCKED.
7. Investigate failures.
8. Create deterministic Playwright regression tests when justified.
9. Run the relevant regression tests.
10. Save the final test summary under reports/.

Do not report PASS without verification.

The exact implementation can evolve, but the workflow remains:

text

Requirement
 ↓
Analyze
 ↓
Plan
 ↓
Execute
 ↓
Observe
 ↓
Verify
 ↓
Investigate
 ↓
Automate
 ↓
Report

24. Generative AI Testing vs Agentic AI Testing

text

Capability                   | Generative AI Testing | Agentic AI Testing
-----------------------------|-----------------------|---------------------------
Generate test cases          | Yes                   | Yes
Generate Playwright code     | Yes                   | Yes
Generate test data           | Yes                   | Yes
Analyze requirements         | Yes                   | Yes
Open application             | Not by itself         | Yes, through tools
Execute browser actions      | Not by itself         | Yes
Observe application behavior | Limited               | Yes
Decide next action           | Usually prompt-driven | Yes
Adapt execution              | Limited               | Yes
Investigate failures         | Assisted              | Autonomous/semi-autonomous
Goal-oriented workflow       | Limited               | Core capability
MCP/tool usage               | Optional              | Major component

25. Recommended Learning Path

Stage 1 — Generative AI

Learn how to use Copilot to generate test cases, Playwright tests, API tests, and test data, and to analyze failures.

Stage 2 — Copilot Agent Mode

Move from "generate code" toward: understand the repository, modify code, run tests, analyze results.

Stage 3 — Playwright MCP

Connect GitHub Copilot → MCP → Playwright MCP → Browser. Learn how the AI interacts with the real application.

Stage 4 — Custom SDET Agent

Create .github/agents/sdet-agent.agent.md and give it requirement analysis, test planning, execution, validation, and failure analysis responsibilities.

Stage 5 — Specialized Agents

Separate the roles: QA Orchestrator, Requirement Analyst, Test Planner, Test Executor, Defect Analyst, Regression Engineer.

Stage 6 — Enterprise Integration

Add additional systems: Jira, GitHub, REST APIs, databases, AWS, CI/CD, reporting, and human approval. The architecture becomes:

text

Requirements
     ↓
AI QA Orchestrator
     ↓
Test Planning
     ↓
UI + API + DB Validation
     ↓
Failure Investigation
     ↓
Defect Management
     ↓
Regression Automation
     ↓
GitHub PR
     ↓
CI/CD

Final Summary

The evolution of AI-assisted testing can be understood as:

text

Traditional Testing

SDET creates and executes automation

             ↓

Generative AI Testing

AI helps SDET generate testing assets

             ↓

Agentic AI Testing

AI agents help plan, execute, observe,
reason, validate, and investigate
testing workflows using tools

For a GitHub Copilot-based Agentic Testing architecture:

GitHub Copilot = AI reasoning environment
Custom Copilot Agents = Specialized SDET roles
MCP = Standardized connection between AI and tools
Playwright MCP = Browser tools available through MCP
Playwright = Browser automation engine
Traditional Playwright Suite = Deterministic regression automation

The goal is not to replace SDETs or traditional Playwright frameworks. The stronger Quality Engineering model is:

text

Human Engineering Judgment

        +

GitHub Copilot AI Reasoning

        +

Agentic Tool Usage

        +

Playwright MCP

        +

Deterministic Playwright Automation

        +

CI/CD

Together, these technologies allow Quality Engineering teams to move from simply asking AI to generate tests toward AI systems that can help understand requirements, design scenarios, interact with applications, validate behavior, investigate failures, and continuously strengthen the permanent automation suite.

Get Playwright tutorials in your inbox

Weekly tips, real-world examples, and framework patterns – no spam, unsubscribe anytime.

1. Overview: Generative AI Testing

2. What Is Agentic AI Testing?

3. Where GitHub Copilot Fits

4. Do We Need .agent.md Files for Generative AI?

5. GitHub Copilot Custom Agent

6. Repository-Level Copilot Instructions

7. What Is MCP?

8. What Is Playwright MCP?

9. Configuring Playwright MCP

10. Basic Agentic Test Example

Step 1 — Navigate

Step 2 — Inspect UI

Step 3 — Decide

Step 4 — Execute

Step 5 — Observe Again

Step 6 — Verify

11. Designing Multiple SDET Agents

12. Requirement Analyst Agent

13. Test Planner Agent

14. Test Executor Agent

15. Defect Analyst Agent

16. Regression Test Engineer

17. Why Traditional Playwright Tests Are Still Important

18. Least-Privilege Agent Design

19. Guardrails for Agentic Testing

20. Enterprise Agentic Testing Architecture

21. Example Enterprise Workflow

22. Recommended Project Structure

23. Example Orchestrator Prompt

24. Generative AI Testing vs Agentic AI Testing

25. Recommended Learning Path

Stage 1 — Generative AI

Stage 2 — Copilot Agent Mode

Stage 3 — Playwright MCP

Stage 4 — Custom SDET Agent

Stage 5 — Specialized Agents

Stage 6 — Enterprise Integration

Final Summary

Get Playwright tutorials in your inbox

Playwright Framework Series

API Testing Series

Recommended Next Articles

Agentic AI Testing with GitHub Copilot, MCP, and Playwright: Complete Guide for SDETs

Playwright MCP Tutorial: Use AI Agents to Control Browsers and Generate Playwright Tests

How Can GitHub Copilot Write Complete Playwright Tests?

How to Integrate AI and GitHub Copilot with a Playwright Automation Framework

Why CI/CD Matters for Playwright Automation: From Local Testing to Enterprise Delivery

Playwright Test Data Management: Build Reliable, Scalable, and Parallel-Safe Automation Tests