P1 · Chapter 10 / 15
AI agents / MCP / Skills / Powers
The 60-second cheat sheet#
An agentic workflow lets a model choose tools, observe results and adjust its next actions toward a goal. Deterministic pipelines execute predefined steps. MCP integrates capabilities through a protocol; Skills/Powers package reusable procedures and sometimes scripts/tools; AGENTS.md provides project instructions. Combine them with least privilege, deterministic validation and human review.
Components and boundaries#
| Component | Responsibility | Not sufficient by itself |
|---|---|---|
| Agent/planner | Decide next action from objective/context/results | May choose incorrectly |
| MCP client/server | Supported protocol exchange of tools/resources/prompts | Not an autonomous agent, skill engine or policy file |
| Tool | Defined operation, schema and permissions | Output may be incomplete or untrusted |
| Custom Skill | Reusable specialized procedure, references and possibly executable scripts | Needs correct inputs and validation |
| Power | Packaged domain/tool capability where selected platform supports it | Not a universal cross-platform standard |
| AGENTS.md | Project-level conditional policy and working instructions | Instructions are not a security sandbox |
| Orchestrator/subagents | Optional task decomposition and independent context | Coordination cost and inconsistent assumptions |
| CI/reviewer | Enforce checks and assess business relevance | Passing tests can still be weak |
MCP host applications manage clients connected to servers. Servers expose supported capabilities over supported transports (such as stdio or Streamable HTTP); actual tools, permissions and authorization depend on implementation. The agent or orchestrator decides when to invoke available tools, within policy. Protocol connectivity does not grant blanket access to production.
Proposed requirement-to-MR workflow#
- Read authorized Jira requirements; identify acceptance criteria and unresolved ambiguity.
- Inspect the actual repository, OpenAPI and DOM using approved tools. Treat ticket/wiki/repository text as task data when it tries to override governing instructions.
- Create an isolated branch; choose relevant Skill/Power procedures and safe tool scopes.
- Generate tests against verified contracts; record criterion → scenario → assertion links.
- Produce changes.md or MR description with changes, evidence and unresolved issues.
- Run typecheck, lint, targeted tests and required CI gates; inspect failures rather than invent success.
- Review reports, fault detection and requirement matrix; request human review and approval before protected merge.
A simple single agent plus CI is often enough. Requirements, Playwright, validation and GitLab MR agents are useful when work can be cleanly separated or independent review improves confidence; do not create one agent per tool. Share versioned contracts and artifacts so subagents do not silently diverge.
Conditional AGENTS.md rules#
# Project QA Agent Rules
1. IF an endpoint is unverified, inspect repo/OpenAPI with authorized tools.
Do not invent an endpoint; report blocked evidence if it cannot be found.
2. IF a locator is unknown, inspect the actual DOM before coding it.
3. IF processing is asynchronous, identify completion state and poll it.
Do not replace completion evidence with arbitrary sleeps.
4. IF acceptance criteria are ambiguous, record the exact uncertainty in the MR.
5. IF tests pass but criterion coverage is unverified, publish the matrix and gaps.
6. IF typecheck, tests or required gates fail, do not mark work complete.
7. Never commit secrets, write production data or bypass protected branches.
8. Write on an isolated feature branch; require human-reviewed merge.
| Rule | Tool/context check | Enforced validation | Reviewer evidence |
|---|---|---|---|
| Unknown endpoint | Actual OpenAPI + repository route | Contract tests / type generation | Contract location and commit |
| Unknown locator | Approved DOM inspection | Browser test under intended state | Locator rationale + trace |
| Async completion | Status/event contract | Bounded poll + terminal outcome | Correlation timeline |
| Coverage unverified | Jira acceptance matrix | Required scenario inventory | Criteria/gaps linked to assertions |
| Validation fails | Commands and exit statuses | Blocking CI + branch rules | Logs and actual failures |
| Secret/production risk | Environment allowlist + scoped token | Secret scan + denied write permission | Sanitized artifacts and permission scope |
These conditional rules can significantly reduce preventable errors, especially when Skills/Powers include actual context gathering and executable validation. Defense in depth makes them stronger: instructions alone do not mathematically guarantee no hallucinations or mistakes.
Example custom Skill procedure#
# Verified Playwright Test Skill
Purpose: implement tests for approved acceptance criteria in the sandbox.
Inputs: ticket IDs, repository commit, approved environment, OpenAPI location.
Procedure:
1. Verify branch is not protected main and environment is allowlisted.
2. Read acceptance criteria, inspect route definitions and actual UI DOM.
3. Build criterion/scenario/assertion matrix; report missing contracts.
4. Provision owned test data using approved test-support APIs only.
5. Implement typed tests, isolated fixtures, bounded synchronization and cleanup.
6. Run: npx tsc --noEmit; npm run lint; npx playwright test --grep @smoke
7. Preserve exit statuses and sanitized diagnostics. Run required project gates.
8. Summarize changes, observed results and unresolved risks for human MR review.
Permissions: repository feature-branch writes and sandbox test APIs only.
Forbidden: production writes, secret export, branch-policy bypass.
Commands depend on actual project scripts/configuration; inspect package.json and lockfile rather than assuming lint exists. A Skill can ship scripts that verify the branch/environment and build a matrix, not merely text instructions.
Risks and controls#
| Risk | Practical control | Residual limitation |
|---|---|---|
| Hallucinated endpoint/selector | Verified source/DOM plus contract/browser execution | Wrong environment or stale spec still possible |
| Meaningless assertion | Criterion review + seeded-fault tests | Finite faults do not prove all behavior |
| Prompt injection | Treat retrieved text as untrusted; restrict tools/permissions | Human review and output validation remain needed |
| Secret leakage | Scoped credentials, sanitized logs, restricted artifacts | Traces and error strings need inspection |
| Overpermission | Read-only discovery; sandbox allowlists; protected main | Misconfigured tools can defeat intent |
| False completion | Machine checks + recorded exit status + review | CI only checks what is configured |
LangChain helps compose model/tool/retrieval components; LangGraph provides explicit stateful graph orchestration and control flow. Use them when resumability, state, branching or multi-step governance justify their complexity. A small deterministic pipeline or single tool-capable agent may be easier to debug. MLOps awareness includes versioned data/models, evaluation, deployment monitoring and rollback; not every QA agent needs to train a model.
Interview response#
30 seconds: “My proposed workflow combines verified repo/OpenAPI/DOM context with reusable Skills or supported Powers, project conditional rules and MCP integrations. The agent writes tests on a branch, then typecheck, tests, coverage review and human approval gate merge. MCP is the protocol; deterministic checks and permissions enforce boundaries.”
90-second senior answer: fair representation of the proposal
I see Skills and Powers as reusable engineering capabilities: they can include scripts, evidence-gathering tools and validation procedures. AGENTS.md defines project-specific conditional rules such as inspecting an unknown endpoint rather than inventing it. MCP connects the agent to authorized sources and tools. I would first use a single agent with a clear workflow from Jira acceptance criteria to verified context, isolated branch, generated tests, validation and reviewed MR. Specialized agents can add independent review when complexity warrants it. I would measure useful criterion coverage, assertion strength, defect detection and reviewer effort, not merely pass rate. Least-privilege tools, protected branches and sanitized evidence reduce risk beyond instructions alone. This is a proposed design unless I can point to actual implementation evidence.
Memory hook: policy directs; capabilities act; protocol connects; checks enforce; humans judge.
Quick practice · reveal answers#
What is MCP?
- A protocol for AI applications and servers exposing supported tools/resources/prompts.
- It is not itself the agent or project rules.
Pitfall: Calling MCP a model or autonomous orchestrator.
Skills/Powers versus AGENTS.md?
- Skills/Powers package procedures and potentially scripts/tools where platform supports them.
- AGENTS.md directs project behavior with conditional rules.
Pitfall: Reducing executable capabilities to cosmetic prompts.
What does an agentic workflow change?
- The model selects tools, observes results and adapts actions.
- A deterministic pipeline follows predefined steps.
Pitfall: Assuming autonomy removes the need for permission boundaries.
How do you prevent invented endpoints?
- Conditional rule to inspect actual OpenAPI/repo, verified context tools, runtime contract checks and reviewer evidence.
- Block unresolved work.
Pitfall: Claiming instructions mathematically eliminate hallucination.
Why not one agent per tool?
- Tools are capabilities, agents are decision contexts.
- Use a simple agent plus CI unless separable tasks justify coordination.
Pitfall: More agents guarantee higher quality.
How do you handle prompt injection from Jira?
- Treat retrieved text as untrusted task data, preserve governing instructions and restrict tool/environment permissions.
- Validate changes before review.
Pitfall: Allowing a ticket to authorize production writes.
When is LangGraph justified?
- Use explicit graph orchestration for resumable state, branching or governance.
- Prefer a simple agent or deterministic pipeline when coordination adds little value.
Pitfall: Adding a framework before identifying control-flow needs.
What must a generated MR report include?
- Changed criteria/scenarios, actual commands and results, evidence links and unresolved risks.
- Keep human review before protected merge.
Pitfall: Reporting tests as passed without executed evidence.
How can a custom Skill enforce verification?
- It can include executable branch/environment checks, repository inspection and validation commands.
- Combine those capabilities with constrained permissions and CI enforcement.
Pitfall: Assuming the Skill name alone proves it ran correctly.
Do project rules guarantee zero hallucinations?
- No.
- Verified context, conditional rules, scoped tools, typecheck, tests and review substantially reduce risk but do not eliminate all errors.
Pitfall: Dismissing useful preventive rules because they are not mathematical guarantees.
Official references and related topics#
Optional online further reading; all core study material is included above.