11 posts tagged with "Agents"

A rule file states policy, and it cannot refuse unfinished work. In part 4, I connect the runtime that supplies tools, credentials and isolation, a delivery graph that orders the work, and a loop that bounds repair.

Before an agent repeats an action, I recommend defining the feedback it reads, the rule that stops it, and a recovery record that survives a crash. Loop engineering, in this series, means observing state, choosing an action, reading feedback and deciding to continue, retry, stop or hand back. That is my framing for these posts, not a standards claim.

When I know the order a workflow must follow, I write that order down explicitly and let the model work inside one step at a time. The drawn route decides what runs next. It cannot prove that a draft is good, and a stored hash can tell me approved bytes changed but not whether the change helped.

A check can return success while a task criterion remains unmet. In harness engineering, I recommend checking the context and the completion evidence before you change models.

Two valid changes to the same service inside fifteen minutes at 2 a.m. is where the outage lives, and single-metric dashboards stay green the whole time. Cloudflare wrote a postmortem about this blind spot: stacked low-signal anomalies that every alert checks alone and nobody checks together. I turned it into an enforceable playbook, so the next on-call learns the pattern from a document and not from an incident.

If AI agents can open pull requests, secret scanning has to block the merge. A scanner that only reports will write accurate notes about a key that already reached the protected branch. My baseline has three layers: a pre-commit hook for fast feedback, a required CI check for enforcement, and a break-glass path (a controlled emergency bypass) that policy governs and audit logs record.

I reviewed the GitGuardian MCP integration pattern and tested it against agent-generated pull requests. MCP is the Model Context Protocol, a standard way for an AI agent to call external tools. My call: teams shipping AI-assisted code should adopt this now.

Most multi-agent failures are orchestration failures, and a smarter model does not repair a handoff that never said what done means. Before I tune any model, I would implement four controls: typed handoffs, explicit state contracts, step-level evals and transactional rollback. GitHub's engineering deep dive, published on February 24, shows the same core pattern.

Vibe coding an AI agent means you tweak a prompt, rerun it and ship when the output feels right. The feeling is the only check, and a feeling does not run in continuous integration (CI), the pipeline that tests every change. I build agents the way I build any other software: modular code, mocked dependencies (test stand-ins that return a fixed answer) and tests written before the logic.

Asking a Drupal site which PHP version it runs should not require an SSH key and a terminal. I built Project Context Connector, a Drupal module that exposes a read-only JSON snapshot of site configuration to AI agents, automation scripts and monitoring tools. Each tool reads the same snapshot through one of four interfaces: REST, an HMAC-signed endpoint (a request signed with a shared secret), Drush or native Model Context Protocol (MCP) support.

The first version of this Drupal agent could create, read and list nodes. That proved the concept, but it could not fix a typo in the content it had created. A content operations agent also needs update, delete, users, taxonomy and media, and it has to survive a flaky network, so retry logic now lives once in the HTTP client.

A skill from a public marketplace arrives with code, setup instructions and a download count. The download count is no evidence of safety. I built Skills Sentry, a static scanner that reads a skill bundle without running it and scores its risk before the bundle touches my machine.