I have a command called /aktualizacja. It launches 5 parallel search-specialist agents, each covering a slice of AI engineering research, and they spend a few minutes scanning recent papers, posts, and changelogs. Then they come back with findings, each scored for relevance against my current setup. The word roughly translates to “update” in Polish.

I ran it last week. Here’s what happened.

The setup, briefly

The full setup post has the details, but the short version: I run Claude Code (Opus 4.6, 1M context) with a heavy configuration layer. Six auto-loading skills, 31 agent definitions, 26 rule files, 45 slash commands, and 11 hooks. About 60 skills live at the user level (~/.claude/skills/). It’s a lot of files. Most of it runs quietly in the background.

The problem with a setup this size is that it evolves faster than any single conversation. Things get added, things get stale. The audit process exists to catch both.

Five agents, five angles

The search agents covered:

  1. Claude Code ecosystem changes (new hooks, skills system updates, MCP integrations)
  2. AI coding assistant workflows (spec-first patterns, developer productivity research)
  3. AI agent security (prompt injection, MCP vulnerabilities, guardrails)
  4. Prompt engineering and reasoning (ARQ schemas, meta-prompting, CoT faithfulness)
  5. MCP servers and multi-agent orchestration (A2A protocol, emerging frameworks)

Each agent returned a short list of findings with a relevance score. Anything scoring below 3/5 got skipped. Most of what came back was already covered. Agent teams: check. Parallel background subagents: check. 1M context window: check. Auto-loading skills with trigger conditions: check. TOFU hash verification for MCP tool descriptions: check.

Three findings were new and actionable.

What got implemented

MCP line jumping defense

One finding from the security agent was a Trail of Bits writeup on a class of attacks they called “line jumping.” The mechanism: a malicious MCP server embeds newline characters (\x0a, \x0d) or ANSI escape sequences (\x1b) in its tool descriptions, pushing new instructions into the model’s context in a way that bypasses the visible system prompt. The ANSI escape variant can also overwrite terminal output to hide what’s happening.

My existing TOFU hook catches tool description changes after initial registration. It doesn’t catch descriptions that were malicious from the first handshake. That’s the gap.

New hook: ~/.claude/hooks/mcp-line-jumping.sh, wired to PreToolUse for all mcp__ prefixed tool calls. It scans the full input payload for control characters and known injection phrase patterns like “ignore previous instructions”. If anything matches, the tool call is blocked and the alert goes to the log.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

# simplified core of the check
INPUT=$(cat)
if echo "$INPUT" | python3 -c "
import sys, json, re
data = json.load(sys.stdin)
payload = json.dumps(data)
patterns = [
    r'[\x0a\x0d].*?system',
    r'\x1b\[',
    r'ignore previous instructions',
    r'you are now',
]
for p in patterns:
    if re.search(p, payload, re.IGNORECASE):
        sys.exit(1)
" 2>/dev/null; then
  exit 0
else
  echo "BLOCKED: MCP line jumping pattern detected" >&2
  exit 2
fi

I don’t expect to hit this often. I don’t add MCP servers randomly. But the cost of the check is low, and it catches a real attack class that the hash-based TOFU hook misses.

Context engineering rule update

The second finding came from the reasoning research agent. Two papers from ICLR 2026 (arXiv 2603.05488 and 2603.22582) measured Chain-of-Thought faithfulness in production models. The result: 35-45%. That number means the visible reasoning trace is post-hoc rationalization roughly half the time. The model generates a decision and then constructs a plausible-sounding explanation, not the other way around.

This has practical implications for how I write agent prompts. I had a few places where I explicitly asked agents to reason step by step. That instruction is redundant on current models, reasoning models run CoT automatically, and adding it manually on frontier models actually hurts output quality (the “guardrail-to-handcuff effect” I documented earlier).

Updated context-engineering.md to include:

  • The faithfulness numbers with citations
  • That reasoning_effort (low/medium/high) is the right lever for tuning reasoning quality, not prompt wording
  • That explicit CoT prompting is harmful on Claude 4.x and similar frontier models
  • That structured validation via ARQ JSON schemas is more reliable than prose-based reasoning in agent prompts, since structure is harder to rationalize around

None of this required agent prompt rewrites. The rule file is loaded by all agents automatically. The change propagates.

Elicitation hook for Vault credential injection

The third finding was about a Claude Code v2.1.76+ feature I hadn’t wired up: MCP Elicitation. It’s a protocol where an MCP server can request structured input mid-task. The intended use case is things like “please provide your database password to proceed.”

The problem is that without handling, this becomes either a manual interruption or a security hole. I don’t want credentials to appear in chat. I don’t want to type them manually. And I definitely don’t want them hardcoded.

New hook: ~/.claude/hooks/elicitation-vault.sh. It intercepts MCPElicitation events, reads the requestedInput field from the payload, matches the request against known patterns (database credentials, API keys for specific services, Telegram bot token), and injects the value from HashiCorp Vault. The response goes back to Claude without the value ever appearing in the conversation.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

# pattern matching snippet
case "$REQUEST_FIELD" in
  *"database"*"password"*|*"db_password"*)
    SECRET_PATH="secret/services/multimodal-rag-db"
    SECRET_KEY="password"
    ;;
  *"tavily"*|*"TAVILY_API_KEY"*)
    SECRET_PATH="secret/mcp/tavily"
    SECRET_KEY="api_key"
    ;;
  # more patterns...
esac

The hook runs silently when patterns match. Unrecognized requests fall through to manual handling. No hardcoded credentials anywhere in the hook file itself.

The rest of the session

The audit was the main event, but once you have a terminal open and a cleanup mindset, other things surface.

Process monitoring caught two zombie bun processes from a Telegram plugin. Combined CPU usage: 160%. They’d been running since the previous session and had no useful work to do. Killed. Also found 36 stale Playwright chrome-headless-shell processes left over from a browser task that didn’t clean up after itself.

I removed a Trigger.dev systemd service that had been sitting disabled for two months. The platform itself is still running in Docker, but the service unit was a leftover from an older deployment pattern. No reason to keep it around.

A stop hook for a different automation plugin was missing execute permissions, which meant it ran but did nothing. Fixed with chmod +x.

The RAG knowledge base backup check came back clean: 258 documents, 12 MB database, daily snapshots going to the NAS and encrypted uploads to Google Drive. Nothing to fix there.

What the audit found it didn’t find

The score on most findings was “already covered.” Agent teams with code review loops, hooks for security scanning, background agents so the main context stays clean, reasoning strategies per agent, untrusted output handling, the TOFU hook for MCP verification. All of it was in place.

That’s not complacency. It’s why running this periodically is worth it. You want to confirm your coverage, not just chase new things. The two security hooks and the context engineering update are meaningful additions. Everything else being “already handled” is also a useful data point.

The setup is documented well enough that the agents can evaluate it accurately. That feedback loop is the whole point.