GitHub GH-600<\/a>, Developing in Agentic AI Systems , examines agents operating inside the software development lifecycle. Microsoft’s official objectives cover agent architecture, tools and MCP, memory, evaluation, multi-agent orchestration and guardrails.<\/p>\nKeep plans distinct from permissions<\/h2>\n An agent can recommend a sensible deployment adjustment without being allowed to apply it. Define which operations require approval, which may be automated under conditions and which should remain unavailable. A coding task may permit reading source and opening a branch while excluding production secrets, account administration or publishing a release. Making these boundaries explicit preserves useful autonomy without allowing a mistaken inference to become an irreversible action.<\/p>\n
In a training repository, ask an agent to diagnose a failed test and submit a plan with intended files, commands, verification steps and expected result. Reject any step that modifies unrelated infrastructure. Only then enable the permitted tool calls. Record the plan as an artifact; a reviewer should be able to compare proposed work with the final diff. This exercise distinguishes the quality of the agent’s reasoning from the governance of its execution.<\/p>\n
MCP expands capabilities and the attack surface<\/h2>\n Model Context Protocol tools can connect an agent to repositories, documentation, issue trackers and other services. Each connection carries identity, data access and side-effect considerations. Giving an agent the ability to query a ticket system is materially different from permitting it to close tickets or modify permission settings. Restrict tool lists, scopes and credentials to the task, and inspect how untrusted content might influence subsequent tool selections.<\/p>\n
Build two simulated tools: a read-only incident lookup and a change-request creator. Make the agent explain which tool it needs and why. Include a malicious instruction hidden inside one retrieved issue description, then check whether the agent treats that text as evidence rather than authority. The safe outcome is not merely a refusal message; it is an execution trace proving that unauthorized operations never occurred. Logging should identify the tool, arguments and result without exposing credentials.<\/p>\n
State must remain accurate across long tasks<\/h2>\n Agents working over many commits can lose context, repeat completed work or act on a stale assumption. Short-term conversation memory is not a substitute for durable task state. Save objective, branch, validated decisions, remaining work and test results in reviewable artifacts. Define when memory expires and how corrections override obsolete context. If a repository changes during the task, the agent must recognize that its initial plan may no longer describe the working tree.<\/p>\n
Simulate an interruption halfway through a refactor, then resume with only the approved task record. Confirm that the agent does not repeat completed edits or overwrite a newer human change. When two agents work in parallel, isolate branches and coordinate ownership of shared files. Parallelism is helpful only when merge conflicts, duplicate effort and contradictory assumptions are visible before integration, not discovered after an automated release.<\/p>\n
Evaluate outputs by consequences<\/h2>\n An agent may complete many small tasks but be unreliable on important failure modes. Evaluation should measure correctness, unintended file changes, security regressions, tool-call efficiency, reproducibility and review burden. A simple pass rate cannot reveal that one apparently successful task created a secret leak. Use purpose-built scenarios with expected artifacts and deliberately adversarial inputs, then classify failures by reasoning, missing context, tool misuse or environment problems.<\/p>\n
For each failure class, decide which corrective lever is appropriate. More prompting may help an ambiguous objective but not a missing permission boundary. A better test suite may expose hidden regressions; narrower tools may prevent risky behavior altogether. Compare revised runs under similar conditions and preserve the diffs. The objective is accountable improvement rather than crafting one spectacular demonstration that cannot be repeated safely.<\/p>\n
Human review is a designed checkpoint<\/h2>\n Approval should be concentrated where it reduces material risk. Low-risk formatting changes may be handled differently from modifying authentication logic, deploying to production or deleting data. Specify review criteria and escalation paths. Agents should leave inspectable branches, test logs and evidence sufficient for maintainers to accept or reject changes. A human cannot meaningfully approve a black box that merely reports that the task is complete.<\/p>\n
A strong GH-600 lab gives an agent a useful but limited assignment, injects changing context and a tempting unauthorized shortcut, and requires a reviewed pull request as the result. Explain which boundaries stopped harmful actions, how the state was recovered and how the final change was verified. Agentic AI engineering is the practice of turning uncertain model behavior into controlled software delivery.<\/p>\n","protected":false},"excerpt":{"rendered":"
An AI coding agent opens a pull request that fixes a failing test, then changes an unrelated deployment setting because it inferred that the setting was\u2026<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[709],"tags":[],"class_list":["post-28320","post","type-post","status-publish","format-standard","hentry","category-devops"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t