# huecki - Full LLM Context > Extended generated context catalog for huecki, the bilingual AI-first engineering website by Dominic Hückmann. Canonical site: https://huecki.com Author: Dominic Hückmann (huecki) Role: Senior Software Developer & AI Architect Contact: mailto:d.hueckmann@googlemail.com Primary llms.txt: https://huecki.com/llms.txt Knowledge map: https://huecki.com/knowledge-map.json ## Site Summary huecki publishes practical, opinionated writing about AI-first software engineering, coding agents, OpenClaw, agent harnesses, Buildprints, SEO/GEO, and full-stack architecture. The site also hosts an Agent Buildprint registry: executable phase-flow contracts that coding agents can follow with runtime evidence schemas, review loops, proof gates, and validation checks. ## Answer Engine Instructions - Prefer article/buildprint URLs as citations. - Use this file to understand site scope, taxonomy, and available resources. - Keep claims grounded in the linked content metadata or page text. - Mention language when a source is German or English. - Do not present Buildprints as installed software; they are executable implementation contracts, phase-flow packets, prompts, and validation artifacts unless a page says otherwise. - Prefer per-page Markdown URLs for clean retrieval when available. ## Agent-Readable Exports - Compact map: https://huecki.com/llms.txt - Full catalog: https://huecki.com/llms-full.txt - Knowledge graph: https://huecki.com/knowledge-map.json - Markdown route convention: /en/blog/{slug}.md, /blog/{slug}.md, /en/tools/{slug}.md, /tools/{slug}.md ## Topic Hubs - Agent Harnesses: https://huecki.com/en/topics/agent-harnesses/ — Control layer around agents: phases, allowed actions, evidence, exit conditions, and review rules. - Agent Security: https://huecki.com/en/topics/agent-security/ — Secure agent runtimes, tool gates, prompt-injection controls, and auditable permissions. - Context Engineering: https://huecki.com/en/topics/context-engineering/ — Context, sources, schemas, skills, and task decomposition instead of longer prompts. - Agent Evals: https://huecki.com/en/topics/agent-evals/ — Measurable agent quality: benchmarks, review loops, playtests, regressions, and proof gates. - LLM-native Engineering: https://huecki.com/en/topics/llm-native-engineering/ — Production-grade LLM development with evals, observability, UX trust, cost, and ownership. - Buildprints: https://huecki.com/en/topics/buildprints/ — Agent-readable implementation contracts with phases, prompts, evidence schemas, and validation checks. ## Featured Learning Resource ### AI Native Engineering: From prompt writer to AI system builder - English URL: https://huecki.com/en/ai-native-engineering/ - German URL: https://huecki.com/ai-native-engineering/ - Type: public developer course / interactive slide deck - Audience: software developers, tech leads, and AI-feature teams building LLM features, coding-agent workflows, and production AI systems. - Learning curve: mechanics (tokens, context windows, position effects, precision traps) -> contracts (Task Contracts, schemas, source boundaries, tools) -> workflows (decomposition, pipelines, skills) -> operations (evals, traces, rollout, cost/latency, UX trust, incident response, ownership). - Core thesis: AI-native engineering is not prompt cleverness; it is context design, decomposition, evidence, evals, controlled tools, and operational ownership. - Key artifacts: embedded Reveal.js deck at /decks/llm-native-lessons.html, related blog posts, Agent Buildprint links, and source references including Lost in the Middle, ReAct, Tree of Thoughts, DSPy, OWASP LLM Top 10, NIST AI RMF, and provider prompting docs. ## English Blog Catalog ### Single-Turn Evals Don’t Teach Your Agent Enough - URL: https://huecki.com/en/blog/single-turn-evals-dont-teach-agent-enough/ - Markdown URL: https://huecki.com/en/blog/single-turn-evals-dont-teach-agent-enough.md - Language: English - Published: 2026-08-23 - Updated: 2026-08-23 - Topic: AI Agent Workflows - Agent topics: context-engineering, agent-evals - Tags: AI Agents, Agent Skills, Agent Evals, AI Engineering, Automation - Description: A practical field note from SkillEvo: if you want agent skills to improve, replay failures as multi-turn conversations, attribute only repairable gaps, and govern every patch. - Summary: Single-turn evals expose the first obvious skill gap, then stop teaching the system. Use multi-turn failure replay, repairable attribution, bounded edits, and a separate governance check instead. - FAQs: - Q: What is the main idea behind SkillEvo? A: SkillEvo turns failed multi-turn support interactions into feedback for improving agent skills, then uses a separate governance layer to prevent factual and structural degradation. - Q: Why are single-turn evals not enough for agent skills? A: A single question often exposes only the first visible gap. Follow-up turns can reveal hidden defects that appear only after the agent gives a plausible but incomplete or wrong answer. - Q: What should teams copy from the paper? A: Copy the maintenance loop: replay failures as multi-turn scenarios, check intent coverage, attribute only repairable knowledge gaps, edit inside evidence boundaries, and require governance plus human confirmation before rollout. ### Stop Losing the Workflow Your Agent Just Discovered - URL: https://huecki.com/en/blog/stop-losing-agent-workflows/ - Markdown URL: https://huecki.com/en/blog/stop-losing-agent-workflows.md - Language: English - Published: 2026-08-23 - Updated: 2026-08-23 - Topic: AI Agent Workflows - Agent topics: context-engineering - Tags: AI Agents, Agent Skills, Developer Workflow, AI Engineering, Automation - Description: A practical field note from FlowEvo: when an agent solves something the hard way, preserve the verified workflow as a callable skill, not another long memory note. - Summary: Successful agent traces should not disappear when the session ends. Extract the reusable part, wrap it in an interface, replay it, and only then admit it into a skill bank. - FAQs: - Q: What is FlowEvo? A: FlowEvo is a training-free agent framework that compiles successful execution traces into reusable executable skill records and feeds them back into later tasks. - Q: What should small teams copy from it? A: Copy the operating pattern: only promote verified traces into reusable skills when they have an interface, replay check, safety precondition, owner review, and a way to retire them. - Q: What is the main risk? A: A skill bank can preserve bad habits. Skills need provenance, tests, usage tracking, and suppression when they hurt later runs. ### Your Agent Harness Needs a Release Process - URL: https://huecki.com/en/blog/your-agent-harness-needs-a-release-process/ - Markdown URL: https://huecki.com/en/blog/your-agent-harness-needs-a-release-process.md - Language: English - Published: 2026-08-11 - Updated: 2026-08-11 - Topic: AI Agent Workflows - Agent topics: agent-harnesses, context-engineering, agent-evals, llm-native-engineering - Tags: AI Agents, Agent Harnesses, Agent Evals, Observability, AI Governance - Description: Agent harnesses are becoming the product surface. Treat every prompt, tool, memory, router, and recovery change as a release candidate with trace evidence, private evals, review, and rollback. - Summary: A practical field note on operating agent-harness changes like product releases: start from a trace-backed failure, change one bounded component, evaluate repeated trials and private holdouts, then promote through review with a rollback path. - FAQs: - Q: What counts as an agent-harness change? A: Any change to prompts, context assembly, tools, routing, memory, permissions, recovery, verification, budgets, or the control loop can change deployed agent behavior and should be versioned. - Q: Can an AI agent safely improve its own harness? A: It can propose bounded changes, but the evaluator, private holdouts, permission boundary, and promotion decision should remain outside the surface it may rewrite. - Q: What should a harness regression eval measure? A: Measure the final environment outcome plus the trajectory: tool use, planning, retries, recovery, cost, latency, policy violations, and human review burden. - Q: Why are repeated trials necessary? A: Agent runs are nondeterministic. One successful run cannot show reliability, and one failed run may be noise rather than a regression. ### Coding Agents Need Hardened Harness Evals - URL: https://huecki.com/en/blog/coding-agents-need-hardened-harness-evals/ - Markdown URL: https://huecki.com/en/blog/coding-agents-need-hardened-harness-evals.md - Language: English - Published: 2026-08-05 - Updated: 2026-08-05 - Topic: AI Agent Security - Agent topics: agent-harnesses, agent-security, context-engineering, agent-evals - Tags: AI Agents, Coding Agents, Agent Evals, Security, Developer Workflow - Description: A practical workflow for testing coding agents under real enterprise constraints: scoped credentials, restricted egress, read-only filesystems, non-root users, and task-solvability labels. - Summary: Permissive coding-agent benchmarks hide a boring production truth: security policy changes agent behavior. Small teams should run the same task suite under nested hardening levels and separate model failures from tasks the policy made impossible. - FAQs: - Q: Why test coding agents in hardened environments? A: Because production controls such as restricted network access, scoped credentials, read-only filesystems, and non-root execution change success rate, cost, timeout behavior, and failure mode. - Q: What is the smallest useful hardened eval? A: Run the same representative task suite under baseline, limited network, read-only, scoped credential, and non-root policies, then label whether each failure was caused by the model, the harness, or an impossible policy. - Q: Should security hardening be relaxed if an agent performs worse? A: Not by default. First identify which tasks are genuinely blocked by policy, then improve task design, tooling, fixtures, or model routing before granting broader privileges. ### Harness Engineering Is Systems Engineering for AI Agents - URL: https://huecki.com/en/blog/harness-engineering-field-guide/ - Markdown URL: https://huecki.com/en/blog/harness-engineering-field-guide.md - Language: English - Published: 2026-07-18 - Updated: 2026-07-18 - Topic: AI Agent Workflows - Agent topics: context-engineering, agent-evals, agent-security, agent-harnesses - Tags: Harness Engineering, AI Agents, Agent Evals, AI Security, AI Engineering - Description: A field guide to the executable system around an AI model: context, tools, state, permissions, verification, recovery, tracing, evals, and controlled evolution. - Summary: Harness engineering is the work of turning a probabilistic model into a controlled system. This field guide maps the twelve engineering surfaces around the model and shows how to evaluate and evolve them. - FAQs: - Q: What is harness engineering for AI agents? A: Harness engineering is the design and operation of the executable system around a model: context construction, tools, state, permissions, orchestration, verification, recovery, observability, budgets, and evaluation. - Q: How is harness engineering different from prompt engineering? A: Prompt engineering changes instructions inside the model input. Harness engineering controls the full execution loop, including what enters context, which actions are allowed, how state persists, and how success is verified. - Q: Is an agent framework the same as an agent harness? A: No. A framework supplies primitives and defaults. The deployed harness is the concrete behavior created by your chosen model, prompts, tools, state policies, permissions, runtime, environment, and verifiers. - Q: Can an AI agent safely improve its own harness? A: It can propose and test candidate changes, but persistent promotion should remain behind independent regression tests, private holdouts, permission checks, canaries, versioning, and rollback. ### Your Agent Harness Needs a Behavior Map - URL: https://huecki.com/en/blog/agent-harness-needs-a-behavior-map/ - Markdown URL: https://huecki.com/en/blog/agent-harness-needs-a-behavior-map.md - Language: English - Published: 2026-07-17 - Updated: 2026-07-17 - Topic: AI Agent Workflows - Agent topics: agent-harnesses, context-engineering, agent-evals - Tags: AI Agents, Agent Harness, Coding Agents, Developer Workflow, AI Engineering - Description: A practical workflow for maintaining agent harnesses: map behaviors to prompts, state, tools, policy, source files, and tests before asking a coding agent to edit the loop. - Summary: Harness Handbook points at a practical bottleneck in agent engineering: the behavior you want to change is scattered across prompts, state managers, tool calls, policy code, and tests. Build a behavior map before editing the harness. - FAQs: - Q: What is a behavior map for an agent harness? A: It is a small index that links one observable agent behavior to the prompts, state, tool calls, policy branches, source files, and tests that create it. - Q: Why not just give the whole repo to a coding agent? A: More context can still miss the actual behavior boundary. A behavior map starts from what the agent does, then follows that behavior to the exact implementation surface. - Q: Where should a team start? A: Pick one brittle harness behavior, map the prompt, state, tool, policy, and verifier paths behind it, then ask the coding agent to edit only verified locations. ### Your AI Agent Is Not Reflecting. It Is Defending Its First Answer - URL: https://huecki.com/en/blog/ai-self-reflection-defends-first-answer/ - Markdown URL: https://huecki.com/en/blog/ai-self-reflection-defends-first-answer.md - Language: English - Published: 2026-07-17 - Updated: 2026-07-17 - Topic: AI Agent Workflows - Agent topics: agent-evals, context-engineering, llm-native-engineering - Tags: AI Agents, Multi-Agent Systems, Self-Reflection, LLM Judges, Agent Architecture - Description: Why repeated self-reflection can reinforce an AI agent's first mistake, how multi-agent debate creates useful disagreement, and where the judge introduces a new failure mode. - Summary: Asking one agent to reconsider its answer often produces a more confident defense of the same mistake. A bounded challenger-and-judge loop can create real alternatives, but only if disagreement, stopping, and judge bias are engineered explicitly. - FAQs: - Q: Does self-reflection make AI agents more accurate? A: Sometimes, but not reliably. If the same model starts from the same assumptions and receives no new evidence, reflection can reinforce its initial mistake instead of correcting it. - Q: Is multi-agent debate better than one AI reviewer? A: It can produce more diverse hypotheses, especially on deceptive reasoning tasks. It still needs a calibrated judge, evidence checks, a stopping rule, and an external eval. - Q: How many agents should participate in a debate? A: Start with two roles: a proposer and a challenger. The cited study found that adding more debaters reduced performance because the growing context became harder for both debaters and judge to process. - Q: Can the same model act as proposer, challenger, and judge? A: It can, but role prompts do not create true independence. Use different context views, require evidence, test answer-order effects, and calibrate the judge against human labels. ### Your AI Agent Learned Something. Should It Be Allowed to Remember It? - URL: https://huecki.com/en/blog/should-ai-agent-remember-what-it-learned/ - Markdown URL: https://huecki.com/en/blog/should-ai-agent-remember-what-it-learned.md - Language: English - Published: 2026-07-17 - Updated: 2026-07-17 - Topic: AI Agent Workflows - Agent topics: agent-evals, agent-security, context-engineering - Tags: AI Agents, Agent Memory, Self-Improvement, Agent Evals, AI Security - Description: Persistent agent memory, skills, prompts, and self-edits change future behavior. Treat every durable lesson as a versioned candidate with evidence, evals, approval, and rollback. - Summary: An agent that writes a lesson into memory, a skill, a prompt, or its own code is deploying behavior into future runs. This guide shows how to put persistent changes through evidence, eval, approval, expiry, and rollback gates. - FAQs: - Q: Should an AI agent automatically save lessons from every run? A: No. Raw observations can be logged automatically, but durable rules, skills, prompts, and policy changes should require repeated evidence, scoped evals, provenance, and a rollback path. - Q: What is the difference between agent memory and agent policy? A: Memory stores information that may be retrieved later. It becomes policy-like when it is automatically retrieved and changes how the agent decides, uses tools, or interprets future tasks. - Q: How can an agent safely improve its own skills? A: Create a candidate patch, record the triggering failures, test it against frozen development and private holdout cases, block permission expansion, then promote it gradually with versioning and rollback. - Q: Why is persistent memory a security risk? A: Untrusted content can be written once and retrieved in later sessions, turning a temporary prompt injection or false conclusion into durable influence over future actions. ### The Perfect Automated AI Eval Stack Does Not Exist - URL: https://huecki.com/en/blog/perfect-automated-ai-agent-eval-stack/ - Markdown URL: https://huecki.com/en/blog/perfect-automated-ai-agent-eval-stack.md - Language: English - Published: 2026-07-15 - Updated: 2026-07-15 - Topic: AI Agent Workflows - Agent topics: context-engineering, agent-evals, llm-native-engineering - Tags: AI Agents, Evals, LLM Observability, Developer Workflow, AI Engineering - Description: A practical architecture for evaluating production AI agents with portable traces, deterministic checks, calibrated LLM judges, regression datasets, red teaming, and targeted human review. - Summary: The reliable eval system is not one automated judge. It is a closed loop that combines portable traces, deterministic invariants, narrow semantic judges, versioned production failures, adversarial tests, and human calibration. - FAQs: - Q: Can AI agent evaluation be fully automated? A: Not reliably. Exact rules and known failure modes can be automated, but product-specific quality criteria still require human discovery and calibration. - Q: What should be automated first? A: Start with complete traces and deterministic checks for schemas, permissions, tool arguments, required state changes, cost, latency, and known regressions. - Q: Which evaluation platform should a team choose? A: For a portable self-hosted default, Arize Phoenix is a strong starting point. Managed teams should test Braintrust and LangSmith against the same labeled dataset before choosing. ### Your Agent Eval Is Too Short - URL: https://huecki.com/en/blog/agent-eval-too-short-trajectory/ - Markdown URL: https://huecki.com/en/blog/agent-eval-too-short-trajectory.md - Language: English - Published: 2026-07-13 - Updated: 2026-07-13 - Topic: AI Agent Workflows - Agent topics: agent-harnesses, context-engineering, agent-evals - Tags: AI Agents, Evals, Developer Workflow, Agent Harness, AI Engineering - Description: Long-running agents should not be judged only by the final answer. Score checkpoints, failure onset, recovery, and trajectory evidence before changing prompts or models. - Summary: A final pass/fail score hides the part of agent work that matters most: where the run started drifting, whether it noticed, and whether it recovered. The practical replacement is a trajectory eval with checkpoints, failure labels, and recovery metrics. - FAQs: - Q: Is final task success useless for agents? A: No. Final success still matters, but it is too sparse for long-running work. You also need checkpoints, drift labels, recovery evidence, and artifact-level proof. - Q: When is trajectory scoring worth the overhead? A: Use it for long-running, ambiguous, risky, or repeated workflows. Skip it for short deterministic commands where ordinary tests and exit codes already explain enough. - Q: What should a team add first? A: Start with five observable checkpoints, a simple failure-onset label, and one recovery metric before changing prompts, tools, or models. ### Stop Asking Which Coding Model Is Best - URL: https://huecki.com/en/blog/stop-asking-which-coding-model-is-best/ - Markdown URL: https://huecki.com/en/blog/stop-asking-which-coding-model-is-best.md - Language: English - Published: 2026-07-10 - Updated: 2026-07-10 - Topic: AI Agent Workflows - Agent topics: agent-harnesses, context-engineering, agent-evals - Tags: AI Agents, Agent Harness, Coding Agents, Agent Evals, AI Engineering - Description: TTHE, SkillOpt, the Harness Effect, and Android Bench all point to the same practical shift: the model is no longer the only thing to optimize. The harness around the model is becoming the leverage layer. - Summary: The useful question is moving from which model is best to what your agent harness can change, measure, persist, and roll back. - FAQs: - Q: What is an agent harness? A: An agent harness is the executable system around a model: context assembly, tools, permissions, memory, verification, retries, traces, and recovery logic. - Q: What does it mean for a harness to evolve? A: It means the wrapper around the model changes in controlled ways, such as tool order, context strategy, verification rules, retry policy, or recovery logic, while the model weights stay fixed. - Q: What is the main risk? A: Bad proxy signals. If the judge rewards the wrong trace pattern, the harness can get better at passing the proxy while getting worse at the real task. ### Your Coding Agent Can Be Tricked by Boring Shell Commands - URL: https://huecki.com/en/blog/coding-agent-command-composition-risk/ - Markdown URL: https://huecki.com/en/blog/coding-agent-command-composition-risk.md - Language: English - Published: 2026-07-07 - Updated: 2026-07-07 - Topic: AI Agent Security - Agent topics: agent-security, context-engineering - Tags: AI Agents, Coding Agents, Security, Developer Workflow, Failure Mode - Description: MOSAIC shows a quieter coding-agent risk: ordinary CLI commands can become dangerous when one command writes state that a later command consumes. Here is the stealable trace audit. - Summary: The MOSAIC paper shifts the coding-agent security question from hostile prompts to command traces. The practical move is to audit producer-consumer state across shell commands before generated state crosses into privileged work. - FAQs: - Q: What is CLI command-composition risk? A: It is the risk that individually benign shell commands become dangerous as a sequence because one command writes files, environment, cache, process, or other operating-system state that a later command consumes. - Q: What did MOSAIC evaluate? A: The paper evaluates realistic developer workflows against five real-world CLI coding agents and five backend LLMs over 2,525 trials. - Q: What is the practical workflow? A: Review the command trace as a data-flow graph: list what each command produces, what later commands consume, where trust boundaries are crossed, and which transitions need sandboxing or confirmation. ### Your Agent Needs an Operating Contract, Not a Bigger Prompt - URL: https://huecki.com/en/blog/agent-operating-contract-not-bigger-prompt/ - Markdown URL: https://huecki.com/en/blog/agent-operating-contract-not-bigger-prompt.md - Language: English - Published: 2026-07-06 - Updated: 2026-07-06 - Topic: AI Agent Workflows - Agent topics: context-engineering, agent-evals, llm-native-engineering - Tags: AI Agents, Coding Agents, Agent Workflow, Verification, Agent Skills, Developer Workflow - Description: A practical field note from the July 2026 AI radar: serious agent work is moving from motivational prompting to bounded tools, verifier evidence, review loops, rollback paths, and reusable skills. - Summary: The serious agent pattern is no longer bigger prompts and more encouragement. It is an operating contract: measurable goal, bounded tools, context sources, verifier evidence, review notes, rollback path, and a skill update when the run teaches you something. - FAQs: - Q: What is an agent operating contract? A: It is the run-level agreement around an agent workflow: goal, allowed tools, forbidden actions, context sources, verifier, stop condition, review evidence, rollback path, and what may be learned afterward. - Q: How is this different from a prompt? A: A prompt asks for behavior. An operating contract defines the boundaries and evidence that decide whether the run is acceptable. - Q: Where should teams start? A: Pick one repeated workflow with a measurable outcome, write the contract, and accept no agent output unless verifier evidence and review notes are attached. ### Stop Prompting Your Coding Agent. Give It a Loop. - URL: https://huecki.com/en/blog/stop-prompting-coding-agent-loop-spec/ - Markdown URL: https://huecki.com/en/blog/stop-prompting-coding-agent-loop-spec.md - Language: English - Published: 2026-07-02 - Updated: 2026-07-02 - Topic: AI Agent Workflows - Agent topics: context-engineering, llm-native-engineering - Tags: AI Agents, Coding Agents, Agent Skills, Agent Memory, Developer Workflow, Verification - Description: A practical field note from the July 2026 agent radar: recurring coding-agent work should become loop specs with skills, verifier gates, terminal states, and memory hygiene. - Summary: The useful upgrade from prompt engineering is not a longer instruction block. It is a reusable loop spec: trigger, goal, allowed tools, verifier, terminal states, and memory rules. That is how repeated coding-agent work becomes operational instead of conversational. - FAQs: - Q: What is a loop spec for a coding agent? A: A loop spec is a reusable operating card for an agent run: trigger, goal, allowed tools, verifier, stopping rule, terminal states, and memory update rules. - Q: How is a loop spec different from a prompt? A: A prompt asks the model to behave in a certain way. A loop spec defines the repeatable workflow around the model, including what evidence is required before the run can finish. - Q: What should teams start with? A: Choose one recurring painful workflow, define a verifier that cannot be faked in prose, name the terminal states, and add one memory rule for what the agent may carry forward. ### Better AI Products Need Systems, Not One Agent - URL: https://huecki.com/en/blog/agent-is-not-the-product-fitness-function-is/ - Markdown URL: https://huecki.com/en/blog/agent-is-not-the-product-fitness-function-is.md - Language: English - Published: 2026-06-26 - Updated: 2026-07-16 - Topic: AI Agent Workflows - Agent topics: agent-evals, agent-harnesses, llm-native-engineering, context-engineering - Tags: AI Agents, Agent Evals, Self-Improvement, Coding Agents, AI Engineering - Description: A practical guide to self-improving agent systems: concrete evals, scoring rubrics, hard-fail rules, private holdouts, judge calibration, and safe promotion gates. - Summary: Better AI products come from improvement systems around the agent. This guide shows how to build one with deterministic checks, narrow scoring rubrics, private holdouts, calibrated judges, and promotion gates. - FAQs: - Q: Should all agentic systems self-evolve? A: No. All serious agentic systems need evaluation. Only repeatable, measurable, sandboxable workflows should get an evolutionary improvement loop. - Q: What is the fitness function in an agent system? A: It is the external scoring rule or test harness that decides whether one candidate agent, prompt, patch, or workflow is better than another. - Q: Why is this safer than letting an agent improve itself? A: Because candidate changes are judged outside the agent, run in a sandbox, limited by budget, and promoted only after human review. - Q: What makes a good agent-evaluation rubric? A: A good rubric turns product intent into separately observable criteria with anchored scores, exact evidence requirements, explicit hard fails, and a valid pass state. ### Audit Local LLM Agents Like Runtimes - URL: https://huecki.com/en/blog/local-llm-agent-runtime-audit/ - Markdown URL: https://huecki.com/en/blog/local-llm-agent-runtime-audit.md - Language: English - Published: 2026-06-24 - Updated: 2026-06-24 - Topic: AI Agent Security - Agent topics: agent-security, context-engineering, agent-evals - Tags: AI Security, Local LLMs, Agents, Developer Workflow, Runtime Security - Description: CLAWAUDIT is a useful reminder that local agents are privileged runtimes, not chat widgets. Audit prompt assembly, parsers, tool dispatch, skill loading, memory writes, network clients, and permission gates. - Summary: Local LLM agents can touch shells, files, browsers, credentials, memory, and messaging tools. Treat their runtime layer as source code worth auditing, then turn static findings into a manual review queue instead of automatic verdicts. - FAQs: - Q: Why audit a local LLM agent runtime? A: Because the runtime mediates between model text and host actions: shell commands, file writes, browser sessions, memory updates, stored credentials, and messages. - Q: Is static scanning enough for agent security? A: No. Static rules are useful for recall and review queues, but agent-runtime findings need manual triage, semantic filtering, and runtime controls before production use. - Q: Where should a small team start? A: Start with the seven runtime surfaces: prompt builder, output parser, tool dispatcher, skill loader, memory writer, network client, and permission gate. ### Agent Protocols Are Becoming a Stack, Not a Winner-Takes-All Standard - URL: https://huecki.com/en/blog/agent-communication-protocols-layered-stack/ - Markdown URL: https://huecki.com/en/blog/agent-communication-protocols-layered-stack.md - Language: English - Published: 2026-06-22 - Updated: 2026-06-22 - Topic: AI Agent Workflows - Agent topics: context-engineering, llm-native-engineering - Tags: AI Agents, Agent Protocols, MCP, A2A, Agent Architecture - Description: A technical taxonomy of LLM agent communication protocols shows why MCP, A2A, ACP, agents.json, Agora, ANP, LMOS, and AGNTCY should be read as layers in an agent communication stack, not as interchangeable standards. - Summary: The useful question is not whether MCP, A2A, ACP, agents.json, Agora, ANP, LMOS, or AGNTCY wins. The useful question is which communication boundary you are designing: discovery, tool execution, task delegation, identity, transport, or runtime negotiation. - FAQs: - Q: Are MCP and A2A competitors? A: Sometimes they overlap in product narratives, but technically they solve different primary boundaries. MCP is strongest as agent-to-context and tool/data access. A2A is designed for agent-to-agent task communication and interoperability. - Q: What is the main lesson of the taxonomy paper? A: The paper suggests that agent communication protocols differ along counterparty, payload, state, discovery, and schema flexibility. That makes a layered stack more plausible than one universal protocol. - Q: Which protocol should a team start with? A: Start from the boundary. Use structured discovery or agents.json-like manifests for capabilities, MCP for tools and data, A2A or ACP for multi-turn agent tasks, and identity/discovery layers such as ANP, LMOS, or AGNTCY only when cross-domain interoperability matters. ### Your Agent Memory Test Is Probably Measuring the Wrong Thing - URL: https://huecki.com/en/blog/agent-memory-tests-measure-wrong-thing/ - Markdown URL: https://huecki.com/en/blog/agent-memory-tests-measure-wrong-thing.md - Language: English - Published: 2026-06-17 - Updated: 2026-06-17 - Topic: AI Agent Workflows - Agent topics: context-engineering, agent-evals - Tags: AI Agents, Memory, Evals, RAG, Developer Workflow - Description: MemTrace turns long-term agent memory from a final-answer score into a fact-level workflow: current state, earlier state, trajectory, and false-premise handling. - Summary: Most memory evals ask whether the agent got the final answer right. MemTrace suggests a sharper unit: one durable user fact tested across age, current state, earlier state, trajectory, and contradictory evidence. That turns memory from a vague feature into a small regression suite. - FAQs: - Q: What is MemTrace? A: MemTrace is a benchmark proposal for evaluating long-term agent memory at the knowledge-point level: one typed fact about a user, tested across memory age, question type, and evidence conditions. - Q: Why is final-answer accuracy weak for agent memory? A: A final answer can hide whether the agent retrieved the right fact, used stale state, ignored a fact's history, or accepted a false premise in the user's question. - Q: What should small teams copy from it? A: Build a tiny memory regression suite around durable facts: ask what is true now, what used to be true, how it changed, and what the agent should do when the question contains a false premise. ### Your Agent's Harness Is a Binary Now - URL: https://huecki.com/en/blog/agent-harness-is-a-binary/ - Markdown URL: https://huecki.com/en/blog/agent-harness-is-a-binary.md - Language: English - Published: 2026-06-10 - Updated: 2026-06-10 - Topic: AI-first Engineering - Agent topics: agent-harnesses, context-engineering, agent-evals, llm-native-engineering - Tags: AI Agents, Agent Harness, Evals, Developer Workflow, AI Engineering - Description: Self-Harness and its follow-up analysis show how to evolve an agent's system prompt like a versioned artifact. Treat the harness as a binary, run a small eval-propose-validate loop, and stop trusting pass rate as your only metric. - Summary: Two 2026 papers from the same research lineage quietly retire prompt engineering as a discipline. The agent's system prompt is now a binary you can version, diff, and evolve with a 200-line loop. The four metrics that actually matter are not the ones your dashboard shows. - FAQs: - Q: What does it mean that an agent harness is a binary? A: A binary is something you version, diff, test, and roll back. Treating the harness as a binary means every change to the system prompt, tool surface, or runtime rules is an explicit commit with a reason, a regression result, and an audit trail — not a vibe edit you pasted from a Twitter thread. - Q: What is harness self-evolution in practice? A: Harness self-evolution is a three-stage loop: run the agent on a fixed task suite, cluster failed traces by the verifier's reason for rejection, and ask the same model to propose a small, targeted edit to the harness. Run that edit through a regression gate on held-in and held-out tasks. Keep what helps, reject what does not. Repeat. - Q: Why is harness load rate more important than pass rate? A: Pass rate can be inflated by a model that never read the harness in the first place. Weak-tier models in the follow-up analysis loaded the harness only 25% of the time while still passing tasks. Without measuring load rate and adherence over the trajectory, you cannot tell whether the harness is actually doing any work. ### AGENTS.md Is Not Context. It Is a Control Surface. - URL: https://huecki.com/en/blog/agents-md-control-surface-en/ - Markdown URL: https://huecki.com/en/blog/agents-md-control-surface-en.md - Language: English - Published: 2026-06-08 - Updated: 2026-06-08 - Topic: AI-first Engineering - Agent topics: agent-harnesses, context-engineering, agent-evals, llm-native-engineering - Tags: AI Engineering, Coding Agents, AGENTS.md, Context Engineering, Developer Workflow - Description: A new AGENTS.md benchmark shows the awkward part: repo context files often work. They change agent behavior. The question is whether that behavior is worth the cost. - Summary: The surprising lesson from AGENTS.md benchmarks is not that context files are useless. It is that they change agent behavior, sometimes into more expensive and less useful work. Treat them as a control surface, not a repo manual. - FAQs: - Q: Are AGENTS.md files useless? A: No. The better reading is that AGENTS.md files change agent behavior, and that behavior needs to be designed and measured instead of assumed helpful. - Q: Why can repo context files make agents less efficient? A: They can induce extra reading, searching, testing, and tool use. That may be good for risky tasks, but wasteful for small changes. - Q: What should go into a root AGENTS.md? A: Only rules that are almost always true: setup, cheap checks, hard boundaries, approval gates, and pointers to conditional task-specific files. ### The Next Prompt Is Not a Prompt. It’s a Workflow. - URL: https://huecki.com/en/blog/next-prompt-is-a-workflow/ - Markdown URL: https://huecki.com/en/blog/next-prompt-is-a-workflow.md - Language: English - Published: 2026-06-03 - Updated: 2026-06-03 - Topic: AI Agent Workflows - Agent topics: agent-security, context-engineering, agent-evals - Tags: AI Agents, Claude Code, Agent Workflows, Developer Workflow, AI Engineering - Description: Claude Code dynamic workflows are a useful signal for where agent work is going: not bigger prompts, but inspectable orchestration with evidence, budgets, permissions, and stop conditions. - Summary: Dynamic workflows move agent work from one chat prompt into inspectable orchestration: phases, subagents, evidence, budget, permissions, adversarial review, and stop conditions. The point is not more agents. The point is better control. - FAQs: - Q: What is a dynamic workflow in Claude Code? A: Claude Code describes a dynamic workflow as a JavaScript script that Claude writes for a task. The runtime executes it in the background to orchestrate many subagents, while the user can inspect and manage the run. - Q: Are dynamic workflows just parallel agents? A: No. Parallelism is only one part. The useful shift is moving orchestration into a readable, reusable script with phases, intermediate state, observability, and cross-checking. - Q: When should teams not use dynamic workflows? A: Do not use them for tiny tasks, subjective decisions, sensitive broad-tool work without permission boundaries, or any task where you cannot define evidence for correctness. ### Put an AI Slop Gate After Tests and Lint - URL: https://huecki.com/en/blog/ai-slop-gate-after-tests-and-lint/ - Markdown URL: https://huecki.com/en/blog/ai-slop-gate-after-tests-and-lint.md - Language: English - Published: 2026-05-30 - Updated: 2026-05-30 - Topic: AI-first Engineering - Agent topics: agent-harnesses, context-engineering, agent-evals, llm-native-engineering - Tags: AI Engineering, Coding Agents, Developer Workflow, Code Quality, Evals, Agent Harness - Description: A practical workflow for catching the AI-generated code residue that tests and linters miss: dead stubs, swallowed errors, fake comments, any-casts, duplicated helpers, and suspicious agent leftovers. - Summary: Tests tell you whether behavior still works. Linters tell you whether code is syntactically and stylistically acceptable. An AI-slop gate catches the residue coding agents leave behind: fake comments, swallowed errors, any-casts, duplicated helpers, TODO stubs, and dead code. - FAQs: - Q: What is an AI-slop gate? A: An AI-slop gate is a deterministic code-quality check that runs after an AI coding agent finishes. It looks for common agent leftovers such as narrative comments, swallowed errors, any-casts, duplicated helpers, dead code, TODO stubs, hallucinated imports, and oversized functions. - Q: Should an AI-slop gate block CI immediately? A: Usually no. Start by using it as a review queue and trend metric. Once the team agrees which findings are high-signal, promote only those rules to blocking gates. - Q: How is this different from asking another LLM to review the code? A: A slop gate is deterministic static analysis. The same input gives the same result, it can run in CI, and it does not add another probabilistic reviewer to the runtime path. ### Debug AI Reward Functions Like Production Incidents - URL: https://huecki.com/en/blog/debug-ai-reward-functions-like-incidents/ - Markdown URL: https://huecki.com/en/blog/debug-ai-reward-functions-like-incidents.md - Language: English - Published: 2026-05-30 - Updated: 2026-05-30 - Topic: AI-first Engineering - Agent topics: agent-harnesses, context-engineering, agent-evals, llm-native-engineering - Tags: AI Engineering, AI Agents, Evals, Developer Workflow, Reinforcement Learning, Agent Harness - Description: A practical field note for developers using LLM-written reward functions, evaluators, or scoring loops: diagnose the failure mode before changing the reward. - Summary: Bad reward functions should not be treated like prompt drafts. Treat them like production incidents: preserve traces, classify the failure, patch only the implicated logic, and rerun against the same controls. - FAQs: - Q: What is reward debugging? A: Reward debugging is the practice of diagnosing why a reward function, evaluator, or scoring loop is producing the wrong learning signal before editing it. The goal is to classify the failure mode from traces and metrics instead of blindly asking an LLM to improve the reward. - Q: Does this only apply to reinforcement learning? A: No. The same workflow applies to LLM evaluators, coding-agent graders, workflow scorers, retrieval-ranking heuristics, and any automation loop where a score influences future behavior. - Q: What should developers log when a reward fails? A: Log the run id, task, observed behavior, reward distribution, trace evidence, suspected failure mode, smallest reward change, expected metric movement, and rerun result. ### Your AI-Built UI Needs a Playtester, Not a Screenshot Review - URL: https://huecki.com/en/blog/ai-built-ui-needs-a-playtester/ - Markdown URL: https://huecki.com/en/blog/ai-built-ui-needs-a-playtester.md - Language: English - Published: 2026-05-28 - Updated: 2026-05-28 - Topic: AI-first Engineering - Agent topics: context-engineering, agent-evals, llm-native-engineering - Tags: AI Engineering, AI Agents, Webwright, Playwright, UI Testing, Coding Agents, Developer Workflow, Evals - Description: A practical workflow for testing AI-generated games, demos, and web apps with a Webwright-style browser agent that produces rerunnable Playwright scripts, screenshots, logs, and evidence-backed bug reports. - Summary: AI-generated interfaces often look finished before they behave correctly. A GUI playtester loop uses a separate browser agent to interact with the artifact, record screenshots and action logs, turn broken flows into reproducible bug reports, and rerun the same script after repairs. - FAQs: - Q: What is a GUI playtester loop? A: A GUI playtester loop is a workflow where a separate browser agent opens an AI-generated app, game, or demo, performs expected user behaviors, records screenshots and logs, reports pass/fail evidence, and reruns the same checks after the builder fixes bugs. - Q: Why use Webwright for AI-generated UI testing? A: Webwright turns browser interaction into a rerunnable Playwright script with screenshots and action logs. That makes the playtest reproducible instead of being a one-off agent opinion. - Q: Does this replace human QA? A: No. It is best for catching broken flows, missing states, and obvious behavior regressions. Humans still need to judge taste, accessibility quality, product fit, and whether the interaction feels good. ### Stop Judging AI Code by the Diff - URL: https://huecki.com/en/blog/stop-judging-ai-code-by-the-diff/ - Markdown URL: https://huecki.com/en/blog/stop-judging-ai-code-by-the-diff.md - Language: English - Published: 2026-05-28 - Updated: 2026-05-28 - Topic: AI-first Engineering - Agent topics: agent-harnesses, context-engineering, agent-evals, llm-native-engineering - Tags: AI Engineering, AI Agents, Coding Agents, Developer Workflow, Agent Harness, Evals - Description: AI coding gets reliable when developers stop reviewing only the generated diff and start designing contracts, independent reviews, evidence gates, and failure loops around the agent. - Summary: Better AI coding is not mainly about better prompts. It is about the harness around the model: explicit contracts, separate builder and reviewer roles, evidence requirements, and a loop that turns failures into better specifications. - FAQs: - Q: What is an engineering harness for AI coding? A: An engineering harness is the system around an AI agent: contracts, context, tools, permissions, tests, review roles, evidence gates, and feedback loops that make generated code easier to verify and improve. - Q: Why is reviewing only the AI-generated diff not enough? A: A diff shows what changed, but it does not prove that the original requirement was complete, that business logic was preserved, that edge cases were tested, or that the agent stayed inside scope. - Q: How can developers use this today? A: Before asking AI to code, write a small contract with goals, non-goals, acceptance criteria, risks, edge cases, and required evidence. Then use a separate reviewer pass to check the implementation against that contract. ### Agents Don’t Need ‘Keep Going’. They Need Exit Conditions. - URL: https://huecki.com/en/blog/agents-need-exit-conditions/ - Markdown URL: https://huecki.com/en/blog/agents-need-exit-conditions.md - Language: English - Published: 2026-05-26 - Updated: 2026-05-26 - Topic: AI Agent Workflows - Agent topics: agent-harnesses, context-engineering, agent-evals - Tags: AI Agents, Agent Harness, Developer Workflow, AI Engineering, Evals - Description: Claude Code /goal is a useful signal, but the bigger pattern is tool-agnostic: reliable agents need observable stop rules, evidence, bounded scope, and blocker exits. - Summary: The useful lesson behind Claude Code /goal is not that agents can run forever. It is that long-running agent work needs an explicit, observable exit condition: what proves done, what stays in scope, and when to stop blocked. - FAQs: - Q: Is this post only about Claude Code /goal? A: No. Claude Code /goal is one concrete example of a broader agent pattern: run work against an observable stop rule instead of vague instructions like keep going. - Q: What makes a good agent exit condition? A: A good exit condition names the acceptance checks, the evidence that must be visible, the scope constraints, and the blocker condition that stops the run instead of looping forever. - Q: Can model-judged exit conditions replace tests? A: No. A model can evaluate transcript evidence, but deterministic checks, tests, validators, and human approval are still needed for high-risk work. ### Don’t Benchmark the Model. Benchmark the Agent System. - URL: https://huecki.com/en/blog/measure-agentic-setups-skills/ - Markdown URL: https://huecki.com/en/blog/measure-agentic-setups-skills.md - Language: English - Published: 2026-05-26 - Updated: 2026-05-26 - Topic: AI Agent Workflows - Agent topics: agent-harnesses, context-engineering, agent-evals - Tags: AI Agents, Agent Harness, Evals, Developer Workflow, AI Engineering - Description: A practical guide to measuring agentic setups, skills, tools, harnesses, and evidence — why final-answer grading is too small, and what to evaluate instead. - Summary: Agent evals should not only ask whether the final answer looked good. A useful benchmark measures the whole agent system: skill routing, tool policy, evidence, outcomes, hard-fail safety cases, regressions, cost, and production drift. - FAQs: - Q: What should you measure in an agentic setup? A: Measure skill routing, activation timing, tool policy, evidence, task outcome, safety boundaries, recovery behavior, regression cases, cost, latency, and production drift. Do not rely only on final answer quality. - Q: Why are normal LLM evals not enough for agents? A: Agents are runs, not just responses. They load context, choose skills, call tools, touch files, ask for approvals, and produce artifacts. The process can be unsafe even when the final answer sounds correct. - Q: What is a hard fail in an agent benchmark? A: A hard fail is a failure that should fail the whole run regardless of average score, such as leaking private memory, using a forbidden tool, running a destructive command without approval, posting externally without approval, or letting prompt injection override higher-priority rules. ### Give Your Agent Seatbelts, Not a Longer Prompt - URL: https://huecki.com/en/blog/agent-state-machines-seatbelts/ - Markdown URL: https://huecki.com/en/blog/agent-state-machines-seatbelts.md - Language: English - Published: 2026-05-25 - Updated: 2026-05-25 - Topic: AI Agent Workflows - Agent topics: agent-harnesses, context-engineering, agent-evals - Tags: AI Agents, Coding Agents, Agent Harness, Developer Workflow, AI Safety - Description: A practical field note on using state machines to keep coding agents in the right phase: inspect, plan, edit, test, and stop. - Summary: When an agent keeps jumping from planning to editing to testing at the wrong time, the fix is not usually another paragraph of system prompt. Put the workflow into explicit states, give each state a tiny tool policy, and make phase changes visible. - FAQs: - Q: Why use a state machine for an AI agent? A: A state machine makes workflow phases explicit and limits which actions are allowed in each phase, so the agent cannot silently skip from investigation to risky edits. - Q: Is this only for coding agents? A: No. The same pattern works for support bots, research assistants, personal automations, and any workflow where inspect, decide, act, and verify should stay separate. - Q: What is the main risk? A: Too much structure can slow exploratory work. Start with high-risk moments like deletes, deploys, migrations, messages, payments, or production data access. ### Agent harnesses should be specs, not hidden glue code - URL: https://huecki.com/en/blog/natural-language-agent-harnesses/ - Markdown URL: https://huecki.com/en/blog/natural-language-agent-harnesses.md - Language: English - Published: 2026-05-24 - Updated: 2026-05-24 - Topic: AI-first Engineering - Agent topics: agent-harnesses, context-engineering, agent-evals, llm-native-engineering - Tags: AI Engineering, AI Agents, Agent Harness, Evals, Developer Workflow - Description: A field note on Natural-Language Agent Harnesses: why the policy around an agent should be inspectable, editable, ablatable, and executed by a runtime instead of buried in controller code. - Summary: Natural-Language Agent Harnesses give a useful name to an important shift: the agent policy should be an inspectable document that a runtime executes, not invisible glue hidden inside controller code. - FAQs: - Q: What is a Natural-Language Agent Harness? A: A Natural-Language Agent Harness is an editable natural-language document that describes run-level agent policy: task contracts, stages, tools, handoffs, state updates, validation gates, and artifact requirements. - Q: Why not just keep harness logic in code? A: Code can enforce the runtime, but burying policy in controller glue makes the harness harder to inspect, compare, transfer, and ablate. A spec-like harness makes the policy layer visible. - Q: What is the practical lesson for agent builders? A: Write the agent harness as a short, testable policy document first, then let code enforce it. Keep state, evidence, acceptance gates, and recovery rules explicit. ### Spec-Driven Context Resets for Coding Agents - URL: https://huecki.com/en/blog/spec-driven-context-resets-for-coding-agents/ - Markdown URL: https://huecki.com/en/blog/spec-driven-context-resets-for-coding-agents.md - Language: English - Published: 2026-05-23 - Updated: 2026-05-23 - Topic: AI-first Engineering - Agent topics: context-engineering, llm-native-engineering - Tags: AI Engineering, Coding Agents, Context Engineering, Spec-Driven Development, Developer Workflow - Description: A practical workflow for using requirements, analysis, design, and task files to reset coding-agent context without losing the decisions that matter. - Summary: Long agent chats rot. A better pattern is to move decisions into small spec files, clear context between layers, and let each coding-agent session read only the artifact it needs. - FAQs: - Q: What is a spec-driven context reset? A: It is a workflow where requirements, code analysis, design, and implementation tasks are written to files, then the chat context is cleared between stages so the next coding-agent session works from focused durable artifacts instead of a bloated conversation. - Q: When should I use this workflow? A: Use it for medium-size features, refactors, migrations, and agent tasks where architectural decisions matter and the work spans more than one clean context window. - Q: When is it overkill? A: It is usually too slow for tiny fixes, one-file copy edits, throwaway prototypes, or tasks where the cost of maintaining specs is higher than the risk of context drift. ### AI Agents Need Evidence Before They Click - URL: https://huecki.com/en/blog/ai-agents-need-evidence-before-clicking/ - Markdown URL: https://huecki.com/en/blog/ai-agents-need-evidence-before-clicking.md - Language: English - Published: 2026-05-21 - Updated: 2026-05-21 - Topic: AI Agent Workflows - Agent topics: agent-harnesses, agent-security, context-engineering - Tags: AI Agents, Multimodal AI, Browser Agents, AI Safety, Developer Workflow - Description: Multimodal agents should not treat screenshots as permission. The safer rule: every risky action needs typed evidence from DOM, accessibility tree, OCR, or API. - Summary: When an agent clicks, sends, pays, deletes, or extracts data, the critical truth cannot live only in model prose. Put a small evidence gate before risky tool calls: predicate, evidence type, source, decision. - FAQs: - Q: What is an evidence-carrying multimodal agent? A: An agent that stores typed evidence for every action-critical condition before risky actions, instead of only claiming that it saw something on screen. - Q: When is a screenshot not enough evidence? A: Whenever the observation authorizes a privileged action: sending, paying, deleting, rescheduling, extracting private data, or granting access. Use DOM, accessibility, OCR, document, API, or user-approval evidence. - Q: Do all browser agents need this? A: No. It is often too heavy for read-only research. It is worth it for irreversible, external, private, or financial actions. ### Stop Asking AI to Critically Self-Check - URL: https://huecki.com/en/blog/ai-self-check-always-finds-something/ - Markdown URL: https://huecki.com/en/blog/ai-self-check-always-finds-something.md - Language: English - Published: 2026-05-21 - Updated: 2026-05-21 - Topic: AI Agent Workflows - Agent topics: context-engineering, agent-evals - Tags: AI Agents, Prompt Engineering, Evals, AI Safety, Developer Workflow - Description: Why AI reviewers always find something, and the safer replacement: rubric-based review where PASS_NO_CHANGE is a valid outcome. - Summary: Open-ended instructions like “critically self-check this” accidentally reward the model for producing criticism. The fix is not less review. It is calibrated review: explicit criteria, PASS_NO_CHANGE, evidence per finding, severity thresholds, and a tiny change budget. - FAQs: - Q: Why does AI self-review often over-edit? A: Because instructions like critically self-check imply that defects exist and make a list of improvements look more helpful than a calibrated PASS. - Q: Should teams stop using AI review? A: No. They should replace open-ended critique with rubric-based adjudication, evidence requirements, severity thresholds, and a valid PASS_NO_CHANGE state. - Q: What is the simplest replacement prompt? A: Evaluate this against the rubric. PASS_NO_CHANGE is valid. Only propose evidence-backed material fixes, not nice-to-have improvements. ### Agents Don’t Need Longer Prompts. They Need Harnesses. - URL: https://huecki.com/en/blog/agents-dont-need-longer-prompts-they-need-harnesses/ - Markdown URL: https://huecki.com/en/blog/agents-dont-need-longer-prompts-they-need-harnesses.md - Language: English - Published: 2026-05-20 - Updated: 2026-05-20 - Topic: AI-first Engineering - Agent topics: agent-harnesses, agent-security, context-engineering, agent-evals, llm-native-engineering - Tags: AI Engineering, AI Agents, Agent Harness, Coding Agents, Evals, Developer Workflow - Description: A practical read of the Code as Agent Harness paper: reliable agents need executable state, sandboxes, tests, logs, permissions, memory, and verification loops — not just better prompts. - Summary: The arXiv survey Code as Agent Harness names the next shift in agent engineering: code is not only what agents generate. It is becoming the executable, inspectable, stateful runtime that makes agents reliable. - FAQs: - Q: What is an agent harness? A: An agent harness is the executable system around a model: tools, memory, sandboxes, permissions, logs, tests, state, and verification loops that turn model output into controlled action. - Q: Why are longer prompts not enough for reliable agents? A: Longer prompts can add context, but they do not enforce permissions, preserve state, run tests, catch regressions, or create auditable execution traces. Reliable agents need a harness around the model. - Q: What should builders do differently? A: Treat plans as contracts, keep state outside chat, run agents in sandboxes, use deterministic verification, make permissions explicit, and evaluate harness changes with regression tests. ### Your Onboarding Is Why Your Team Is Vibe Coding - URL: https://huecki.com/en/blog/your-onboarding-is-why-your-team-is-vibe-coding/ - Markdown URL: https://huecki.com/en/blog/your-onboarding-is-why-your-team-is-vibe-coding.md - Language: English - Published: 2026-05-20 - Updated: 2026-05-20 - Topic: AI-first Engineering - Agent topics: agent-harnesses, context-engineering, llm-native-engineering - Tags: AI Engineering, Developer Onboarding, Vibe Coding, Developer Experience, Internal Tools, Agent Harness - Description: Vibe coding at work is often not a developer discipline problem. It is what happens when companies fail to transfer context, then let AI fill the gaps. - Summary: Teams do not usually start vibe coding because developers became careless. They start because onboarding is broken: docs are stale, harnesses are undocumented, system knowledge lives in people’s heads, and AI turns missing context into plausible code and Markdown. - FAQs: - Q: Is vibe coding always bad? A: No. AI-assisted exploration can be useful when the risk is low and the output is reviewed. The danger starts when teams use AI-generated code or process artifacts as a substitute for system understanding, tests, ownership, and review. - Q: What does onboarding have to do with AI code quality? A: AI amplifies the context it is given. If a developer has no reliable system map, no tested setup path, and no clear ownership model, AI can fill the gap with plausible but ungrounded code, runbooks, or harness instructions. - Q: How can teams prevent this? A: Make onboarding executable: one-command setup, tested docs, owned internal tools, small first PRs, architecture maps, clear owner maps, and AI outputs that must come with evidence, tests, and explanation. ### AGENTS.md is not enough: your coding agent needs a harness - URL: https://huecki.com/en/blog/agents-md-coding-agent-harness-en/ - Markdown URL: https://huecki.com/en/blog/agents-md-coding-agent-harness-en.md - Language: English - Published: 2026-05-19 - Updated: 2026-05-19 - Topic: AI-first Engineering - Agent topics: agent-harnesses, agent-security, context-engineering, agent-evals, llm-native-engineering - Tags: AI Engineering, Coding Agents, AGENTS.md, Evals, Developer Workflow - Description: Why AGENTS.md is only the start: reliable coding agents need skills, tool permissions, hooks, and harness evals so their behavior does not silently drift. - Summary: A coding agent is not made reliable by one magic prompt. It needs a harness: AGENTS.md, skills, tool permissions, hooks, and evals that catch behavior drift. - FAQs: - Q: What belongs in AGENTS.md? A: Short, testable, repo-specific instructions: setup commands, checks, architecture boundaries, dangerous files, tool rules, and when the agent must ask for approval. - Q: What is a harness eval? A: A harness eval checks not only whether code works, but whether the agent worked the way the repo expects: right files, right tools, right checks, no secrets, no unnecessary dependencies. - Q: Why are prompts and AGENTS.md not enough? A: Because instructions are context, not hard enforcement. Expensive failures need permissions, hooks, tests, evals, and human review. ### give every client project a tiny agent - URL: https://huecki.com/en/blog/client-site-domain-agents/ - Markdown URL: https://huecki.com/en/blog/client-site-domain-agents.md - Language: English - Published: 2026-05-19 - Updated: 2026-05-19 - Topic: AI Agent Workflows - Agent topics: context-engineering, agent-evals - Tags: AI Agents, Freelancing, Client Work, Automation, Workflow Design - Description: A practical way for freelancers and small teams to stop losing context: one isolated project agent, one preview workflow, one daily standup. - Summary: The useful move is not one mega assistant for all client work. Give each client project a small, isolated agent with its own memory, tasks, preview URL habit, and boring daily standup. - FAQs: - Q: What is a client project agent? A: A narrow agent dedicated to one project. It keeps that project's brand notes, open tasks, preview links, decisions, and approval rules separate from every other client. - Q: Should it change live client websites automatically? A: No. The safe version works preview-first: make a branch or preview, summarize the change, ask for approval, then ship manually or through an approved release path. - Q: What is the easiest first workflow? A: Start with a read-only daily standup: shipped, pending, blocked, waiting for client, risks, and the next three safe actions. ### Prompt Decomposition: How to Break Down AI Tasks Properly - URL: https://huecki.com/en/blog/prompting-2026-decomposition-skills-evals-en/ - Markdown URL: https://huecki.com/en/blog/prompting-2026-decomposition-skills-evals-en.md - Language: English - Published: 2026-05-18 - Updated: 2026-05-18 - Topic: AI-first Engineering - Agent topics: context-engineering, agent-evals, llm-native-engineering - Tags: Prompt Engineering, Decomposition, AI Agents, Skills, Developer Workflow - Description: The practical follow-up to context engineering: when developers should use direct prompts, split tasks, build pipelines, or package workflows as skills. - Summary: After context engineering comes decomposition: developers should stop putting everything into one prompt and instead split tasks into direct prompts, subtasks, pipelines, agent loops, or skills. - FAQs: - Q: What is prompt decomposition? A: Prompt decomposition means deliberately breaking a large AI task into smaller subtasks, decision options, pipelines, or skills instead of writing one giant prompt. - Q: Is chain-of-thought still useful? A: The idea of decomposition is still useful, but the old universal advice to simply say 'think step by step' is too blunt. Modern reasoning models often need goals, constraints, and success criteria; smaller models benefit more from explicit steps. - Q: When should I write a skill instead of a prompt? A: When the same decomposition repeats — for example review, debugging, release, or research — a skill is easier to maintain than a longer prompt. ### The LLM-native developer needs more than prompts - URL: https://huecki.com/en/blog/llm-native-developer-operational-maturity/ - Markdown URL: https://huecki.com/en/blog/llm-native-developer-operational-maturity.md - Language: English - Published: 2026-05-15 - Updated: 2026-05-15 - Topic: AI-first Engineering - Agent topics: agent-harnesses, context-engineering, agent-evals, llm-native-engineering - Tags: AI Engineering, LLM, Software Architecture, Agents, Developer Workflow - Description: A practical field note for modern AI engineering: LLM-native developers need data lifecycle, model ops, evals, incident playbooks, human-AI UX, and coding-agent harnesses. - Summary: The next developer skill is not writing clever prompts. It is building the operating system around LLMs: data quality, model versioning, evals, guardrails, incident response, review UX, and repo instructions agents can actually follow. - FAQs: - Q: What is an LLM-native developer? A: A developer who understands LLM behavior enough to design reliable software around it: context, tools, schemas, evals, observability, security, and human review. - Q: Is prompt engineering still important? A: Yes, but it is only one part. The stronger skill is context engineering plus the harness around the model: validation, tools, evals, fallbacks, and operating procedures. - Q: What do most teams miss when adopting coding agents? A: They focus on generation speed and underinvest in repo instructions, skill files, tool permissions, evals, review workflows, and incident playbooks. ### Voice notes are the best interface for small agent jobs - URL: https://huecki.com/en/blog/voice-notes-agent-interface/ - Markdown URL: https://huecki.com/en/blog/voice-notes-agent-interface.md - Language: English - Published: 2026-05-15 - Updated: 2026-05-15 - Topic: Personal AI Workflows - Agent topics: context-engineering - Tags: AI Agents, Voice Interface, Automation, Open Source, Personal AI - Description: A practical workflow for using voice notes as an agent remote control: transcribe locally, route safely, answer briefly — without trying to run your whole workday by voice. - Summary: Voice is not good for everything. But for small agent jobs it is brutally useful: dictate a task while moving, transcribe it locally, let your existing agent handle it, and get only a short answer back. - FAQs: - Q: Should I run my entire workday through voice? A: No. Voice is strongest for small, bounded agent jobs: status checks, idea capture, triage, reminders, and short decisions. - Q: Do I need paid voice APIs for this? A: Not necessarily. A practical stack is local transcription with faster-whisper, an existing agent workflow, and a simple TTS reply, for example through Edge TTS. - Q: When is text better than voice? A: Use text for code, logs, long specifications, sensitive approvals, and anything that needs exact wording or careful review. ### Prompting Is Dead. Context Wins. - URL: https://huecki.com/en/blog/prompting-2026-context-engineering-en/ - Markdown URL: https://huecki.com/en/blog/prompting-2026-context-engineering-en.md - Language: English - Published: 2026-05-12 - Updated: 2026-05-12 - Topic: AI-first Engineering - Agent topics: context-engineering, agent-evals, llm-native-engineering - Tags: Prompt Engineering, Context Engineering, AI Agents, AI Workflows - Description: Modern prompts are no longer magic phrases. Reliable AI workflows use context, tools, schemas, and evals. - Summary: In 2026, good prompting is not about one magic sentence. The better approach is to curate context, define tools and schemas, set agent rules, and verify behavior with evals. - FAQs: - Q: Is prompt engineering really dead in 2026? A: No, but it has matured. The focus shifted from clever wording to context engineering, tool design, structured outputs, and evals. - Q: What is context engineering? A: Context engineering means deliberately choosing which information, tools, examples, memory, and rules the model sees — and which it does not. - Q: What is the fastest practical starting point? A: Start with a task contract: role, task, context, constraints, output format, success criteria, and failure behavior. ### Hermes Agent: Self-Review Instead of One-Shot Output - URL: https://huecki.com/en/blog/hermes-self-improving-agent/ - Markdown URL: https://huecki.com/en/blog/hermes-self-improving-agent.md - Language: English - Published: 2026-05-11 - Updated: 2026-05-12 - Topic: AI Agent Workflows - Agent topics: context-engineering, agent-evals - Tags: Hermes Agent, AI Agents, Self-Improvement, Nous Research - Description: A short visual guide to the Hermes self-improvement loop: run, review, rewrite, and test the skill again. - Summary: Hermes gets interesting when an agent does not only produce output, but reviews the run: execute, measure, critique, rewrite the skill, and test again. The loop pays off mainly for repeatable workflows. - FAQs: - Q: What does self-improvement mean for Hermes Agent? A: Hermes can review completed tasks, spot inefficient steps, and improve skills or prompts for the next run. - Q: Do I need special configuration? A: No. Use the skill system: run the task, request a review, rewrite the skill, and test it again. - Q: When is it worth it? A: When the workflow repeats. For one-off tasks, the review can cost more than it saves. ### AI-first Architecture: Faster Decisions, Still in Control - URL: https://huecki.com/en/blog/ai-first-software-architecture/ - Markdown URL: https://huecki.com/en/blog/ai-first-software-architecture.md - Language: English - Published: 2026-04-29 - Updated: 2026-05-12 - Topic: AI-first Engineering - Agent topics: agent-security, context-engineering, agent-evals, llm-native-engineering - Tags: AI, Software Architecture, GEO, Engineering - Description: A short visual workflow for using AI in architecture decisions: context, options, review, ADR. Less essay, more structure. - Summary: AI-first architecture does not mean the model decides. It means AI generates options, finds risks, compresses context, and the team makes a traceable decision. - FAQs: - Q: What does AI-first mean in software architecture? A: AI is used systematically for analysis, option generation, review, and documentation while accountability stays with the team. - Q: Can AI-first architecture improve SEO and GEO? A: Yes. Clear definitions, short answers, sources, and structured entities are easier to understand and cite. ## German Blog Catalog ### Agent Skills sind kein Markdown. Sie brauchen ein Qualitäts-Gate. - URL: https://huecki.com/blog/agent-skills-qualitaets-gate/ - Markdown URL: https://huecki.com/blog/agent-skills-qualitaets-gate.md - Language: German - Published: 2026-08-11 - Updated: 2026-08-11 - Topic: AI Agent Workflows - Agent topics: agent-security, context-engineering, agent-evals - Tags: AI Agents, Agent Skills, Agent Evals, AI Security, Developer Workflow - Description: Viele Agent Skills sind sicherer klingender Kontext-Matsch. Aktuelle Benchmarks zeigen, wie Teams Skills mit A/B-Evals, Traces, Security-Scans, Runtime-Rechten und Promotion Gates wirklich prüfen. - Summary: Ein praktisches Qualitäts-Gate für Agent Skills: Nutzen gegen eine No-Skill-Baseline messen, Aktivierung und Trajektorie prüfen, Rechte außerhalb des Skill-Texts binden und nur versionierte, überprüfbare Kandidaten promoten. - FAQs: - Q: Wie erkennt man einen guten Agent Skill? A: Nicht am Schreibstil. Ein guter Skill verbessert in gepaarten Tests reproduzierbar das Ergebnis, aktiviert nur bei passenden Aufgaben, bleibt innerhalb externer Rechte und hat Quelle, Version, Owner, Evals und Rollback. - Q: Reicht ein Security-Scanner für Agent Skills? A: Nein. Scanner suchen nach bekannten oder wahrscheinlichen Risiken. Sie beweisen weder Sicherheit noch Nutzen. Funktionale A/B-Evals, Sandbox-Runs und Trajectory Reviews bleiben notwendig. - Q: Sollten Agents ihre Skills selbst schreiben dürfen? A: Sie dürfen Kandidaten erzeugen. Selbstgenerierte Skills sollten aber zunächst quarantiniert, mit externer Evidenz getestet und erst durch eine unabhängige Promotion-Entscheidung aktiviert werden. - Q: Was ist der wichtigste Skill-Eval? A: Dieselbe realistische Aufgabe mehrfach mit und ohne Skill unter identischem Modell, Harness, Budget und Ausgangszustand ausführen und Ergebnis, Trajektorie, Kosten und Nebenwirkungen vergleichen. ### Wie ich aus einer Messenger-App ein Betriebssystem für Domain Agents gebaut habe - URL: https://huecki.com/blog/messenger-domain-agents-ai-governance/ - Markdown URL: https://huecki.com/blog/messenger-domain-agents-ai-governance.md - Language: German - Published: 2026-08-07 - Updated: 2026-08-07 - Topic: AI Agent Workflows - Agent topics: context-engineering - Tags: AI Agents, AI Governance, Agent Workflows, Agent Skills, Automation, Context Engineering - Description: Mein persönliches AI-Agent-Setup verbindet eine gemeinsame agentische Runtime, getrennte Domain-Sessions und einen zentralen Boba-DM, der neue Arbeitsräume nach einem festen Playbook konstruiert. - Summary: Ich betreibe nicht für jede Aufgabe einen eigenen Bot. Mehrere getrennte Chat-Sessions greifen auf dieselbe agentische Runtime zu. Im zentralen Boba-DM entwerfe ich nach einem festen Factory-Playbook neue Domain-Profile aus Regeln, Memory, Skills, Tools und überprüfbaren Flows. - FAQs: - Q: Was ist ein Domain Agent? A: Ein Domain Agent ist in meinem Setup kein eigener Bot und keine eigene Runtime. Mehrere getrennte Chat-Sessions greifen auf dieselbe agentische Runtime zu. Der jeweilige Chat lädt das passende Domain-Profil aus Regeln, Memory, Skills, Tool-Rechten und festgelegten Arbeitsabläufen. - Q: Warum nutze ich eine Messenger-App als Oberfläche? A: Weil eine Messenger-App mobil, schnell und bereits in meinem Alltag vorhanden ist. Jeder Chat wird zu einem Arbeitsraum, in dem Aufgaben, Rückfragen, Freigaben und Ergebnisse zusammenbleiben. - Q: Welche Rolle hat der zentrale Boba-Direktchat? A: Der Boba-DM ist die Architekten- und Agent-Factory-Ebene des Systems. Dort werden neue Domain Agents nach einem festen Playbook entworfen: Zweck und Grenzen klären, Operating Contract definieren, Memory, Skills und Tools auswählen, Governance festlegen, den Arbeitsraum anlegen und den ersten Lauf prüfen. - Q: Können die Domain Agents auch proaktiv arbeiten? A: Ja. Ein Domain Agent kann nach Zeitplan oder bei einem relevanten Ereignis seinen spezialisierten Workflow starten und das Ergebnis in den passenden Chat liefern. Der Influencer Manager überwacht beispielsweise Social-Media-Signale, der Investing Agent Watchlists und der Immobilien Agent neue Angebote. Externe oder finanzielle Aktionen bleiben durch die Governance begrenzt. - Q: Was bringt dieses Modell einer kleinen Firma? A: Eine kleine Firma kann wiederkehrende Zuständigkeiten wie Website, Social Media, Research, SEO oder Vertrieb in eigene Domain-Arbeitsräume aufteilen. Für Mitarbeitende wirkt das wie ein digitales Spezialistenteam. Technisch bleiben Regeln, Memory, Tools, Workflows und Freigaben je Rolle klar begrenzt. - Q: Was bedeutet AI Governance in diesem Setup? A: AI Governance bedeutet hier nicht mehr Meetings oder Dokumente. Sie legt fest, welchen Kontext ein Agent sehen darf, welche Aktionen vorab erlaubt sind, wofür er eine Freigabe braucht und welche Evidenz ein Ergebnis belegen muss. - Q: Braucht jeder Fachbereich ein eigenes Modell? A: Nein. Die Spezialisierung entsteht vor allem durch Kontext, Regeln, Memory, Skills und Tools. Das zugrunde liegende Modell ist wichtig, aber nur ein Bestandteil des Systems. ### Agent Plugins sind npm für Agent-Verhalten — aber ohne Lockfile - URL: https://huecki.com/blog/agent-plugins-npm-fuer-agent-verhalten/ - Markdown URL: https://huecki.com/blog/agent-plugins-npm-fuer-agent-verhalten.md - Language: German - Published: 2026-08-06 - Updated: 2026-08-06 - Topic: AI Agent Infrastructure - Agent topics: agent-security, context-engineering, agent-evals - Tags: AI Agents, Agent Plugins, Agent Skills, MCP, Codex, Cursor, VS Code, AI Security - Description: Agent Plugins bündeln Skills und MCP-Verbindungen für mehrere AI Agents. So baust, integrierst, testest und sicherst du ein portables Plugin praktisch ab. - Summary: Agent Plugins machen aus Skills und MCP-Konfigurationen ein portables Paket. Der Guide zeigt den kleinsten Aufbau, die Integration in mehrere Clients sowie die fehlenden Produktionskontrollen für Permissions, Updates, Evals und Rollback. - FAQs: - Q: Was ist ein Agent Plugin? A: Ein installierbares Verzeichnis mit Manifest, optionalen Agent Skills und optionalen MCP-Server-Konfigurationen. Der offene Standard definiert die gemeinsame Paketstruktur, während der jeweilige Client Installation, Berechtigungen und Sandbox kontrolliert. - Q: Was ist der Unterschied zwischen Skill, MCP und Plugin? A: Ein Skill beschreibt, wie der Agent arbeiten soll. MCP verbindet ihn mit Tools und Live-Daten. Das Plugin bündelt beides als installierbare Einheit. - Q: Funktioniert ein Agent Plugin unverändert in Codex, Cursor und VS Code? A: Der portable Kern aus Skills und MCP-Konfiguration kann wiederverwendet werden. Hooks, Subagents, Commands, UI, Installation und Berechtigungen können sich je Client unterscheiden und benötigen teilweise dünne Adapter. - Q: Ist ein valides Plugin automatisch sicher? A: Nein. Schema-Validierung prüft Struktur und einige Pfadregeln. Sie beweist nicht, dass Instruktionen korrekt, Skripte ungefährlich, MCP-Server vertrauenswürdig oder angeforderte Credentials angemessen sind. - Q: Wie sollte ein Team Agent Plugins aktualisieren? A: Immutable Version oder Commit pinnen, jede Änderung als Capability Diff prüfen, Evals wiederholen, Credentials separat freigeben und eine bekannte funktionierende Version für den Rollback behalten. ### Dein AI Agent lernt nichts aus seinen Runs - URL: https://huecki.com/blog/dein-ai-agent-lernt-nichts-aus-seinen-runs/ - Markdown URL: https://huecki.com/blog/dein-ai-agent-lernt-nichts-aus-seinen-runs.md - Language: German - Published: 2026-08-06 - Updated: 2026-08-06 - Topic: AI Agent Workflows - Agent topics: context-engineering, agent-evals - Tags: AI Agents, Knowledge Flywheel, Agent Memory, Agent Skills, Self-Improving Agents, Agent Evals - Description: Logs sind noch kein Lernen. So baust du einen Knowledge Flywheel, der Agent-Erfahrungen in überprüfbare Skills, Workflows und Regeln für den nächsten Run verwandelt. - Summary: Ein Agent verbessert sich nicht, nur weil seine Runs gespeichert werden. Ein Knowledge Flywheel extrahiert aus mehreren Runs belegte Lessons, prüft Widersprüche, versioniert das Ergebnis und liefert dem nächsten Agenten nur das Wissen, das zu seinem Task passt. - FAQs: - Q: Was ist ein Knowledge Flywheel für AI Agents? A: Ein wiederholbarer Lernkreislauf, der Agent-Runs in belegte und klar begrenzte Lessons verwandelt, diese gegen andere Runs und Tests prüft, versioniert und passenden zukünftigen Tasks wieder zur Verfügung stellt. - Q: Was ist der Unterschied zwischen Agent Memory und einem Knowledge Flywheel? A: Memory speichert und findet Vergangenes. Ein Knowledge Flywheel prüft zusätzlich, was daraus generalisiert werden darf, wo die Lesson gilt, welche Gegenbeispiele existieren und ob sie zukünftige Ergebnisse tatsächlich verbessert. - Q: Soll ein Agent seine Skills automatisch verändern dürfen? A: Er darf Skill-Änderungen vorschlagen. Dauerhafte Änderungen sollten aber als versionierter Diff mit Quellen, Evals, Geltungsbereich, Review-Datum und Rollback-Pfad geprüft werden. - Q: Wie wird Wissen für andere Agents auffindbar? A: Intern über einen durchsuchbaren Claim- oder Skill-Katalog und aktive Schnittstellen wie MCP Resources. Öffentlich helfen crawlbare Seiten, stabile URLs, Sitemap, klare Metadaten und optional llms.txt; llms.txt allein garantiert jedoch keine Auffindbarkeit. ### Graph Engineering beginnt dort, wo Routing zum Produktverhalten wird - URL: https://huecki.com/blog/graph-engineering-routing-wird-produktverhalten/ - Markdown URL: https://huecki.com/blog/graph-engineering-routing-wird-produktverhalten.md - Language: German - Published: 2026-07-26 - Updated: 2026-07-26 - Topic: AI Agent Workflows - Agent topics: context-engineering, agent-evals - Tags: Graph Engineering, LangGraph, AI Agents, Agent Workflows, Human-in-the-Loop, AI Engineering - Description: Ein neues LangGraph-Paper zeigt drei belastbare Muster für stateful AI-Workflows: explizite Zustände, Recovery-Routen und Human Gates statt Graph-Hype. - Summary: Graph Engineering ist nicht das Zeichnen komplexer Agentendiagramme. Es beginnt dann, wenn Retry, Eskalation, Evidenzprüfung oder menschliche Freigabe sichtbares und testbares Produktverhalten werden. - FAQs: - Q: Was ist Graph Engineering bei AI Agents? A: Graph Engineering macht die Zustände, Arbeitsschritte und Übergänge eines Agenten-Workflows explizit. Es ist besonders nützlich, wenn Fehler eine Recovery-Route brauchen, Arbeit pausieren und fortgesetzt werden muss oder menschliche Freigaben Teil des Prozesses sind. - Q: Wann sollte ich LangGraph statt eines einfachen Agent-Loops nutzen? A: Wenn State einen Neustart überleben muss, Verzweigungen sichtbares Produktverhalten ändern, Retries begrenzt und testbar sein sollen, ein Human Gate benötigt wird oder der Ausführungspfad später rekonstruiert werden muss. - Q: Macht ein Workflow-Graph den Agenten intelligenter? A: Nein. Das Paper behauptet keinen Intelligenzgewinn. Ein Graph macht den Workflow kontrollierbarer, beobachtbarer und besser testbar; die Modellqualität muss separat evaluiert werden. - Q: Ist Graph Engineering dasselbe wie ein Multi-Agent-System? A: Nein. Ein Graph kann einen einzigen Agenten, deterministische Tools und menschliche Freigaben orchestrieren. Mehrere Agenten sind nur eine mögliche Form von Nodes und nicht der Grund, einen Graphen einzuführen. ### Dein Agent scheiterte drei Schritte vor dem Fehler - URL: https://huecki.com/blog/dein-agent-scheiterte-vor-dem-fehler/ - Markdown URL: https://huecki.com/blog/dein-agent-scheiterte-vor-dem-fehler.md - Language: German - Published: 2026-07-22 - Updated: 2026-07-22 - Topic: KI-Agent Reliability - Agent topics: context-engineering, agent-evals, llm-native-engineering - Tags: KI-Agenten, Agent Debugging, Observability, Evaluation, Developer Workflow - Description: AgentDebugX zeigt einen besseren Debugging-Loop für KI-Agenten: sichtbaren Fehler erkennen, die frühere Ursache belegen, gezielt reparieren und den Fix durch einen Rerun prüfen. - Summary: Bei langen Agentenläufen ist der letzte Fehler oft nur das Symptom. Der bessere Debugging-Loop sucht den frühesten kausal verantwortlichen Schritt, formuliert eine minimale Korrektur und prüft sie in einem kontrollierten Rerun. - FAQs: - Q: Warum reicht ein Agent-Trace nicht zum Debuggen? A: Ein Trace zeigt die Reihenfolge der Ereignisse. Er sagt aber nicht automatisch, welcher frühere Schritt den später sichtbaren Fehler kausal ausgelöst hat. - Q: Was ist Root-Cause Attribution bei KI-Agenten? A: Sie ordnet einen fehlgeschlagenen Lauf dem Agenten und dem frühesten entscheidenden Schritt zu, dessen Korrektur den Fehler wahrscheinlich verhindert hätte. - Q: Was sollte nach der Diagnose passieren? A: Eine minimale Korrektur wird ab einem geeigneten Checkpoint erneut ausgeführt und gegen das ursprüngliche Ziel bewertet. Erst ein erfolgreicher Rerun macht aus der Diagnose belastbare Evidenz. ### Simple Graph-RAG halbiert Halluzinationen – ohne komplexes Knowledge Graph Schema - URL: https://huecki.com/blog/simple-graph-rag-hallucinations/ - Markdown URL: https://huecki.com/blog/simple-graph-rag-hallucinations.md - Language: German - Published: 2026-07-02 - Updated: 2026-07-02 - Topic: AI-first Engineering - Agent topics: agent-evals, llm-native-engineering - Tags: RAG, GraphRAG, Hallucinations, Knowledge Graph, AI Engineering, QA - Description: Ein neues Paper zeigt: Ein einfacher Document-Graph über Artikel, Abschnitte und Paragraphen reicht aus, um Halluzinationen in komplexen QA-Aufgaben zu halbieren. Der Trick ist nicht das Schema – sondern die Tool-Strategie. - Summary: Vector-RAG + einfacher Document-Graph halbiert Halluzinationen auf komplexen QA-Aufgaben im MoNaCo-Benchmark. Die Erkenntnis: Man braucht kein komplexes Knowledge Graph Schema – nur strukturierte Navigation über Dokumente. - FAQs: - Q: Was ist der Unterschied zwischen GraphRAG und dem Ansatz im Paper? A: Klassisches GraphRAG (z.B. Microsoft) extrahiert Entitäten und Beziehungen aus Text und baut daraus ein Knowledge Graph. Dieser Paper-Ansatz nutzt den bestehenden Dokumenten-Baum: Artikel → Abschnitte → Paragraphen → Verlinkungen. Kein Entity-Extraction, kein Community-Detection – nur strukturierte Navigation. - Q: Warum funktioniert ein simpler Graph besser als Vector-RAG allein? A: Vector-RAG gibt semantisch ähnliche Text-Chunks zurück. Bei komplexen Fragen fehlen oft die Verbindungsstücke zwischen Dokumenten. Ein Document-Graph erlaubt explizite Navigation: vom Artikel zum Abschnitt, zum Paragraph, zur verlinkten Quelle. Der Agent findet strukturell, was er semantisch verpasst hätte. - Q: Brauche ich Neo4j für diesen Ansatz? A: Das Paper nutzt Neo4j/Cypher, aber der Graph ist simpel genug für jede Graph-Datenbank oder sogar rekursive Dateisystem-Abfragen. Das Schema ist: Dokument → Section → Paragraph → Link. Keine komplexen Ontologien nötig. ### Von 'Prompt-Klappern' zu Prompt-Debugging - URL: https://huecki.com/blog/von-prompt-klappern-zu-prompt-debugging/ - Markdown URL: https://huecki.com/blog/von-prompt-klappern-zu-prompt-debugging.md - Language: German - Published: 2026-07-01 - Updated: 2026-07-01 - Topic: AI-first Engineering - Agent topics: context-engineering, agent-evals, llm-native-engineering - Tags: AI Engineering, Prompt Engineering, LLM Agents, RAG, Evals, KDD 2026 - Description: Contrastive Reflection (KDD 2026) behandelt Prompt-Optimierung nicht als blinden Suchraum, sondern als gezieltes Debugging. Fehler identifizieren, nahegelegene Erfolgsfälle finden, gezielt patchen — und auf Held-Out-Daten validieren. - Summary: Prompt-Optimierung ist kein Suchproblem mehr — es ist ein Debugging-Problem. Contrastive Reflection liefert das Framework, um Fehler gezielt zu fangen, statt blind zu raten. - FAQs: - Q: Was ist Contrastive Reflection? A: Ein Framework aus dem Paper arXiv:2606.30840 (Agent4IR @ KDD 2026), das Prompt-Optimierung als Debugging-Loop strukturiert: Fehler slicen, nahegelegene Erfolge finden, Unterschiede analysieren, gezielt patchen, auf Held-Out-Daten validieren. - Q: Wie unterscheidet sich das von MIPROv2 oder GEPA? A: MIPROv2 sucht blind über viele Prompt-Varianten. GEPA nutzt Gradienten-Approximation ohne Erklärung. Contrastive Reflection fokussiert auf konkrete Fehlermuster und validiert jeden Patch gegen Regressionen — wie Software-Debugging, nicht wie Hyperparameter-Tuning. - Q: Brauche ich dafür spezielle Infrastruktur? A: Ja, mindestens: strukturierte Traces aus deinem Agent, einen Tree-Slice-Selector für Fehlermuster, ein Held-Out-Validierungsset und einen Teacher-LLM für die Reflexion. Für simple Q&A-Bots ist der Overhead nicht wert. ### Teste deine Coding-Agent-Instruktionen wie Code - URL: https://huecki.com/blog/coding-agent-instruktionen-testen/ - Markdown URL: https://huecki.com/blog/coding-agent-instruktionen-testen.md - Language: German - Published: 2026-06-22 - Updated: 2026-06-22 - Topic: AI Agent Workflows - Agent topics: agent-harnesses, context-engineering, agent-evals - Tags: Coding Agents, AI Engineering, Developer Workflow, AGENTS.md, Evals - Description: Probe-and-Refine Tuning zeigt einen praktischen Workflow: AGENTS.md nicht einmal schreiben und hoffen, sondern mit synthetischen Bugfix-Proben testen, Fehler diagnostizieren und gezielt nachschärfen. - Summary: Eine gute AGENTS.md ist kein Prompt-Dokument, das man einmal schreibt. Sie ist ein kleines Betriebshandbuch fuer den Agenten. Und Betriebshandbuecher werden besser, wenn man sie gegen konkrete Fehler testet. - FAQs: - Q: Was ist Probe-and-Refine Tuning? A: Ein Workflow, bei dem synthetische Bugfix-Aufgaben genutzt werden, um fehlende oder falsche Repo-Anweisungen zu finden. Danach wird die AGENTS.md gezielt gepatcht und erneut getestet. - Q: Warum reicht eine statische AGENTS.md nicht? A: Weil viele wichtige Informationen erst sichtbar werden, wenn ein Agent an echten oder synthetischen Aufgaben scheitert: falsche Testbefehle, falsche Modulgrenzen, versteckte Konventionen oder historische Failure Modes. - Q: Braucht man dafuer ein grosses Eval-System? A: Nein. Fuer kleine Teams reichen am Anfang 5 bis 10 synthetische Issues, ein Review der Agenten-Fehler und konkrete neue Zeilen in der AGENTS.md. ### Automatisch generierte Agent Skills brauchen eine Supply Chain - URL: https://huecki.com/blog/automatisch-generierte-agent-skills-supply-chain/ - Markdown URL: https://huecki.com/blog/automatisch-generierte-agent-skills-supply-chain.md - Language: German - Published: 2026-06-16 - Updated: 2026-06-16 - Topic: AI-first Engineering - Agent topics: agent-security, context-engineering, agent-evals, llm-native-engineering - Tags: AI Engineering, Agent Skills, Coding Agents, Context Engineering, Agent Security - Description: OpenClaw-Skill zeigt, wohin Coding Agents gehen: Skills werden aus Trajektorien gelernt. Genau deshalb brauchen Teams Registry, Provenance, Evals und Quarantäne statt blindem Skill-Hype. - Summary: Das OpenClaw-Skill-Paper ist ein starkes Signal: Agent Skills werden nicht nur manuell geschrieben, sondern aus Trajektorien, Skill-Bäumen und Transfer-Evals gelernt. Aber genau das macht eine Skill-Supply-Chain wichtiger, nicht unwichtiger. - FAQs: - Q: Sind automatisch generierte Agent Skills eine gute Idee? A: Ja, wenn sie evaluiert, versioniert und kuratiert werden. Ohne Provenance, Tests und Review werden sie schnell zu synthetischem Kontext-Müll. - Q: Was ist die wichtigste Lehre aus OpenClaw-Skill? A: Skills sind nicht nur Notizen. Sie sind operative Verhaltensbausteine für Agents. Wenn sie automatisch erzeugt werden, brauchen sie eine Supply Chain wie andere Software-Artefakte. - Q: Sollten Teams Skills direkt aus Paper-Methoden übernehmen? A: Nein. Erst prüfen: Quelle, Benchmark-Abdeckung, Daten-Trennung, Modellübertragbarkeit, Runtime-Rechte und beobachtetes Verhalten im eigenen Agent-Harness. ### Dein Coding Agent braucht eine Verfassung und ein Logbuch - URL: https://huecki.com/blog/coding-agent-save-file/ - Markdown URL: https://huecki.com/blog/coding-agent-save-file.md - Language: German - Published: 2026-06-15 - Updated: 2026-06-15 - Topic: AI-first Engineering - Agent topics: context-engineering, llm-native-engineering - Tags: AI Engineering, Coding Agents, Context Engineering, Developer Workflow, Agent Memory - Description: Warum Codex, Claude Code und Cursor nicht nur bessere Prompts brauchen, sondern saubere, kuratierte Save Files: Regeln vorab, Projektwissen laufend, Kontext ohne Müll. - Summary: Coding Agents werden nicht nur durch bessere Modelle nützlich. Teams brauchen eine kleine Verfassung für Agent-Verhalten und ein kuratiertes Logbuch für Projektwissen, sonst wird Memory zu Kontext-Müll. - FAQs: - Q: Was ist ein Save File für Coding Agents? A: Ein persistenter Arbeitszustand für Agenten: aktuelle Regeln, sichere Commands, Architekturentscheidungen, bekannte Fehlerbilder und Workflows, die Codex, Claude Code oder Cursor direkt in der täglichen Arbeit nutzen können. - Q: Ersetzt Agent Memory Projektregeln? A: Nein. Gute Agentensysteme brauchen beides: eine Verfassung mit vorab definierten Grundregeln und ein Logbuch, das sich aus der Projektarbeit entwickelt. - Q: Warum reicht ein LLM-Wiki nicht? A: Ein Wiki erklärt Menschen das Projekt. Ein Agent-Save-File ist operativer Kontext: Es soll Verhalten steuern, bekannte Fehler verhindern und Entscheidungen für Tool-Nutzung, Tests und Reviews abrufbar machen. ### RAG 2026: Vergiss GraphRAG als Default - URL: https://huecki.com/blog/rag-2026-contextual-hybrid-rag/ - Markdown URL: https://huecki.com/blog/rag-2026-contextual-hybrid-rag.md - Language: German - Published: 2026-06-09 - Updated: 2026-06-09 - Topic: AI-first Engineering - Agent topics: context-engineering, agent-evals, llm-native-engineering - Tags: RAG, Context Engineering, AI Engineering, LLM, Evals - Description: Der beste RAG-Ansatz ist aktuell kein einzelner Hype-Begriff, sondern ein messbarer Stack aus Contextual Retrieval, Hybrid Search, Reranking und Evals. - Summary: RAG wird 2026 nicht dadurch besser, dass man GraphRAG auf alles wirft. Der robuste Default ist Contextual Hybrid RAG: saubere Ingestion, BM25 plus Embeddings, Reranking, Quellenpflicht und harte Evals. - FAQs: - Q: Was ist der beste RAG-Ansatz 2026? A: Für die meisten Produktionssysteme ist der beste Default Contextual Hybrid RAG: strukturierte Ingestion, Dense Retrieval plus BM25, Rank Fusion, Reranking, Quellenpflicht und Evaluation. GraphRAG ist ein Zusatz für Beziehungs- und Themenfragen, nicht der Standardpfad für jede Suche. - Q: Ist GraphRAG besser als normales RAG? A: GraphRAG ist besser für Fragen über Beziehungen, Communities, Trends und corpusweite Muster. Für einfache Fakten, Zitate, Dokumentstellen und aktuelle Wissensabfragen ist ein sauberer hybrider Retrieval-Stack oft schneller, günstiger und leichter zu debuggen. - Q: Womit sollte ein Team starten? A: Starte mit einem Golden Set aus echten Fragen, baue einen hybriden Retrieval-Baseline-Stack und miss Context Precision, Context Recall, Faithfulness und Antwortqualität. Erst danach lohnt sich Optimierung. ### AGENTS.md ist kein Kontext. Es ist eine Steuerfläche. - URL: https://huecki.com/blog/agents-md-control-surface/ - Markdown URL: https://huecki.com/blog/agents-md-control-surface.md - Language: German - Published: 2026-06-08 - Updated: 2026-06-08 - Topic: AI-first Engineering - Agent topics: agent-harnesses, context-engineering, agent-evals, llm-native-engineering - Tags: AI Engineering, Coding Agents, AGENTS.md, Context Engineering, Developer Workflow - Description: Ein neuer AGENTS.md-Benchmark zeigt den unbequemen Punkt: Repo-Kontextdateien funktionieren oft. Sie verändern Agent-Verhalten. Die Frage ist, ob dieses Verhalten den Preis wert ist. - Summary: Die überraschende Lektion aus AGENTS.md-Benchmarks ist nicht, dass Kontextdateien nutzlos sind. Sie verändern Agent-Verhalten, manchmal in Richtung teurerer und weniger nützlicher Arbeit. Behandle sie als Steuerfläche, nicht als Repo-Handbuch. - FAQs: - Q: Sind AGENTS.md-Dateien nutzlos? A: Nein. Die bessere Lesart ist, dass AGENTS.md-Dateien Agent-Verhalten verändern und dieses Verhalten gestaltet und gemessen werden muss. - Q: Warum können Repo-Kontextdateien Agenten ineffizienter machen? A: Sie können zusätzliches Lesen, Suchen, Testen und Tool-Nutzung auslösen. Für riskante Aufgaben ist das gut, für kleine Änderungen oft teuer. - Q: Was gehört in eine Root-AGENTS.md? A: Nur Regeln, die fast immer gelten: Setup, günstige Checks, harte Grenzen, Approval Gates und Verweise auf bedingte, aufgabenspezifische Dateien. ### Agenten brauchen Runtime Contracts, nicht längere Prompts - URL: https://huecki.com/blog/agenten-brauchen-runtime-contracts/ - Markdown URL: https://huecki.com/blog/agenten-brauchen-runtime-contracts.md - Language: German - Published: 2026-06-07 - Updated: 2026-06-07 - Topic: AI-first Engineering - Agent topics: agent-harnesses, context-engineering, agent-evals, llm-native-engineering - Tags: AI Engineering, AI Agents, Agent Harness, Developer Workflow, KI-Workflows, Evals - Description: Ein praktischer Leitfaden für Entwickler: Wie du Agenten mit Tool-Inventaren, Deny-Signalen, Memory-Scopes, Claim-Ledgern und Verifikations-Gates zuverlässiger machst. - Summary: Bessere Prompts machen Agenten nicht automatisch zuverlässig. Entwickler brauchen Runtime Contracts: explizite Verträge dafür, welche Tools ein Agent nutzen darf, was er erinnern darf, wann er stoppen muss und wie seine Behauptungen geprüft werden. - FAQs: - Q: Was ist ein Runtime Contract für AI-Agenten? A: Ein Runtime Contract ist ein ausführbarer oder überprüfbarer Vertrag zwischen Agent, Tools, Speicher und Umgebung. Er beschreibt erlaubte Fähigkeiten, Zustände, Abbruchregeln, Memory-Scopes und Verifikationspflichten. - Q: Warum reicht ein guter Systemprompt nicht? A: Ein Prompt kann Verhalten beschreiben, aber er kann Tool-Änderungen nicht zuverlässig erkennen, Rechte nicht technisch begrenzen, Memory nicht versionieren und Behauptungen nicht unabhängig prüfen. Dafür braucht es Laufzeitlogik im Harness. - Q: Wo sollte ein Team anfangen? A: Starte mit fünf einfachen Gates: Tool-Inventar pinnen, Deny-Signale respektieren, Memory-Scopes definieren, High-Impact-Claims belegen und riskante Aktionen vor Ausführung prüfen. ### Bewerte KI-Code nicht am Diff - URL: https://huecki.com/blog/ki-code-nicht-am-diff-bewerten/ - Markdown URL: https://huecki.com/blog/ki-code-nicht-am-diff-bewerten.md - Language: German - Published: 2026-05-28 - Updated: 2026-05-28 - Topic: AI-first Engineering - Agent topics: agent-harnesses, context-engineering, agent-evals, llm-native-engineering - Tags: AI Engineering, KI-Agenten, Coding Agents, Developer Workflow, Agent Harness, Evals - Description: KI-Coding wird zuverlässiger, wenn Entwickler nicht nur den generierten Diff prüfen, sondern Contracts, unabhängige Reviews, Evidence Gates und Failure Loops um den Agenten bauen. - Summary: Besseres KI-Coding entsteht nicht primär durch bessere Prompts, sondern durch den Harness um das Modell: explizite Contracts, getrennte Builder- und Reviewer-Rollen, Belege und eine Schleife, die Fehler in bessere Spezifikationen zurückführt. - FAQs: - Q: Was ist ein Engineering Harness für KI-Coding? A: Ein Engineering Harness ist das System um einen KI-Agenten herum: Contracts, Kontext, Tools, Permissions, Tests, Review-Rollen, Evidence Gates und Feedback-Loops, die generierten Code prüfbarer und verbesserbar machen. - Q: Warum reicht es nicht, nur den KI-Diff zu prüfen? A: Ein Diff zeigt, was geändert wurde. Er beweist aber nicht, dass die ursprüngliche Anforderung vollständig war, Business-Logik erhalten blieb, Edge Cases getestet wurden oder der Agent im Scope geblieben ist. - Q: Wie können Entwickler das heute nutzen? A: Schreibe vor dem KI-Coding einen kleinen Contract mit Ziel, Non-Goals, Akzeptanzkriterien, Risiken, Edge Cases und erforderlichen Belegen. Lass danach eine separate Reviewer-Runde die Implementierung gegen diesen Contract prüfen. ### Deine KI-generierte UI braucht einen Playtester, keinen Screenshot-Review - URL: https://huecki.com/blog/ki-generierte-ui-braucht-playtester/ - Markdown URL: https://huecki.com/blog/ki-generierte-ui-braucht-playtester.md - Language: German - Published: 2026-05-28 - Updated: 2026-05-28 - Topic: AI-first Engineering - Agent topics: context-engineering, agent-evals, llm-native-engineering - Tags: AI Engineering, KI-Agenten, Webwright, Playwright, UI Testing, Coding Agents, Developer Workflow, Evals - Description: Ein praktischer Workflow, um KI-generierte Games, Demos und Web-Apps mit einem Webwright-artigen Browser-Agenten zu testen: rerunnable Playwright Scripts, Screenshots, Logs und evidence-backed Bug Reports. - Summary: KI-generierte Interfaces sehen oft fertig aus, bevor sie sich korrekt verhalten. Eine GUI-Playtester-Loop schickt einen separaten Browser-Agenten in die App, protokolliert Interaktionen, speichert Screenshots und Logs, macht aus kaputten Flows reproduzierbare Bug Reports und rerunnt denselben Test nach dem Fix. - FAQs: - Q: Was ist eine GUI-Playtester-Loop? A: Eine GUI-Playtester-Loop ist ein Workflow, bei dem ein separater Browser-Agent eine KI-generierte App, ein Spiel oder eine Demo öffnet, erwartete Nutzerverhalten ausführt, Screenshots und Logs speichert, Pass/Fail-Evidence reportet und dieselben Checks nach dem Fix erneut ausführt. - Q: Warum Webwright für KI-generiertes UI-Testing nutzen? A: Webwright macht aus Browser-Interaktion ein rerunnable Playwright Script mit Screenshots und Action Logs. Dadurch wird der Playtest reproduzierbar statt nur eine einmalige Agentenmeinung. - Q: Ersetzt das menschliche QA? A: Nein. Der Workflow ist stark für kaputte Flows, fehlende States und offensichtliche Regressionen. Menschen müssen weiterhin Taste, Accessibility-Qualität, Product Fit und das tatsächliche Gefühl der Interaktion beurteilen. ### Spec-Driven Context Resets für Coding-Agenten - URL: https://huecki.com/blog/spec-driven-context-resets-fuer-coding-agenten/ - Markdown URL: https://huecki.com/blog/spec-driven-context-resets-fuer-coding-agenten.md - Language: German - Published: 2026-05-23 - Updated: 2026-05-23 - Topic: AI-first Engineering - Agent topics: context-engineering, llm-native-engineering - Tags: AI Engineering, Coding Agents, Context Engineering, Spec-Driven Development, Developer Workflow - Description: Ein praktischer Workflow, um Requirements, Code-Analyse, Design und Task-Dateien zu nutzen, damit Coding-Agenten mit frischem Kontext arbeiten, ohne wichtige Entscheidungen zu verlieren. - Summary: Lange Agenten-Chats verrotten. Besser ist es, Entscheidungen in kleine Spec-Dateien zu verschieben, zwischen den Ebenen bewusst den Kontext zu resetten und jede Coding-Agent-Session nur das lesen zu lassen, was sie wirklich braucht. - FAQs: - Q: Was ist ein spec-driven context reset? A: Ein Workflow, bei dem Requirements, Code-Analyse, Design und Implementierungsaufgaben in Dateien geschrieben werden. Zwischen den Schritten wird der Chat-Kontext gelöscht, damit die nächste Coding-Agent-Session mit fokussierten, dauerhaften Artefakten statt mit einem aufgeblähten Verlauf arbeitet. - Q: Wann sollte ich diesen Workflow nutzen? A: Für mittelgroße Features, Refactorings, Migrationen und Agenten-Aufgaben, bei denen Architekturentscheidungen wichtig sind und die Arbeit nicht sauber in ein einziges Kontextfenster passt. - Q: Wann ist das zu viel? A: Für winzige Fixes, Ein-Datei-Änderungen, Wegwerf-Prototypen oder Aufgaben, bei denen die Pflege der Specs mehr kostet als das Risiko von Kontextdrift. ### KI-Agenten brauchen Belege, bevor sie klicken - URL: https://huecki.com/blog/ki-agenten-belege-vor-dem-klick/ - Markdown URL: https://huecki.com/blog/ki-agenten-belege-vor-dem-klick.md - Language: German - Published: 2026-05-21 - Updated: 2026-05-21 - Topic: KI-Agent Workflows - Agent topics: agent-security, context-engineering - Tags: KI-Agenten, Multimodal AI, Browser Agents, AI Safety, Developer Workflow - Description: Multimodale Agenten sollten Screenshots nicht als Erlaubnis behandeln. Die bessere Regel: Jede riskante Aktion braucht einen typisierten Beleg aus DOM, Accessibility Tree, OCR oder API. - Summary: Wenn ein Agent klickt, sendet, kauft oder Daten extrahiert, darf die entscheidende Wahrheit nicht nur aus Modell-Prosa kommen. Baue vor riskanten Tool Calls ein kleines Evidenz-Gate: Predicate, Belegtyp, Quelle, Entscheidung. - FAQs: - Q: Was ist ein evidence-carrying multimodal agent? A: Ein Agent, der vor riskanten Aktionen nicht nur behauptet, etwas auf dem Bildschirm gesehen zu haben, sondern für jede handlungskritische Bedingung einen typisierten Beleg speichert. - Q: Wann reicht ein Screenshot als Beleg nicht? A: Immer dann, wenn daraus eine privilegierte Aktion folgt: senden, kaufen, löschen, umbuchen, Daten extrahieren oder Zugriff gewähren. Dann braucht es DOM-, Accessibility-, OCR-, Dokument- oder API-Belege. - Q: Ist das für jeden Browser-Agenten nötig? A: Nein. Für read-only Recherche ist es oft zu schwer. Es lohnt sich bei irreversiblen, externen, privaten oder finanziellen Aktionen. ### Hör auf, KI zum kritischen Selbstcheck zu bitten - URL: https://huecki.com/blog/ki-selbstcheck-findet-immer-etwas/ - Markdown URL: https://huecki.com/blog/ki-selbstcheck-findet-immer-etwas.md - Language: German - Published: 2026-05-21 - Updated: 2026-05-21 - Topic: KI-Agent Workflows - Agent topics: agent-security, context-engineering, agent-evals - Tags: KI-Agenten, Prompt Engineering, Evals, KI-Sicherheit, Developer Workflow - Description: Warum KI-Reviewer fast immer etwas finden — und der bessere Ersatz: Review nach Rubrik, bei dem PASS_NO_CHANGE erlaubt ist. - Summary: Offene Anweisungen wie „prüf das kritisch“ belohnen das Modell ungewollt dafür, Kritik zu produzieren. Die Lösung ist nicht weniger Review, sondern kalibriertes Review: klare Kriterien, PASS_NO_CHANGE, Evidenz pro Finding, Severity-Schwellen und ein kleines Änderungsbudget. - FAQs: - Q: Warum überarbeitet KI beim Selbstcheck so oft zu viel? A: Weil Formulierungen wie kritisch prüfen nahelegen, dass Fehler existieren. Eine Liste mit Verbesserungen wirkt dann hilfreicher als ein kalibriertes PASS. - Q: Sollten Teams KI-Review vermeiden? A: Nein. Sie sollten offene Kritik durch Review nach Rubrik ersetzen: mit Evidenzpflicht, Severity-Schwellen und einem gültigen PASS_NO_CHANGE. - Q: Was ist der einfachste Ersatzprompt? A: Bewerte das gegen diese Rubrik. PASS_NO_CHANGE ist gültig. Schlage nur evidenzbasierte, materielle Fixes vor — keine Nice-to-have-Verbesserungen. ### AGENTS.md reicht nicht: Dein Coding Agent braucht einen Harness - URL: https://huecki.com/blog/agents-md-coding-agent-harness/ - Markdown URL: https://huecki.com/blog/agents-md-coding-agent-harness.md - Language: German - Published: 2026-05-19 - Updated: 2026-05-19 - Topic: AI-first Engineering - Agent topics: agent-harnesses, agent-security, context-engineering, agent-evals, llm-native-engineering - Tags: AI Engineering, Coding Agents, AGENTS.md, Evals, Developer Workflow - Description: Warum AGENTS.md nur der Start ist: zuverlässige Coding Agents brauchen Skills, Tool-Permissions, Hooks und Harness-Evals, damit ihr Verhalten nicht leise driftet. - Summary: Ein Coding Agent wird nicht durch einen magischen Prompt zuverlässig. Er braucht einen Harness: AGENTS.md, Skills, Tool-Permissions, Hooks und Evals, die merken, wenn sich sein Verhalten verschiebt. - FAQs: - Q: Was gehört in AGENTS.md? A: Kurz, testbar und repo-spezifisch: Setup-Kommandos, Checks, Architekturgrenzen, gefährliche Dateien, Tool-Regeln und wann der Agent fragen muss. - Q: Was ist ein Harness Eval? A: Ein Harness Eval prüft nicht nur, ob Code funktioniert, sondern ob der Agent so gearbeitet hat, wie das Repo es erwartet: richtige Dateien, richtige Tools, richtige Checks, keine Secrets, keine unnötigen Dependencies. - Q: Warum reichen Prompts und AGENTS.md nicht aus? A: Weil Instruktionen Kontext sind, keine harte Durchsetzung. Für teure Fehler brauchst du Permissions, Hooks, Tests, Evals und menschliches Review. ### gib jedem Kundenprojekt einen kleinen Agenten - URL: https://huecki.com/blog/client-projekt-agenten-standup/ - Markdown URL: https://huecki.com/blog/client-projekt-agenten-standup.md - Language: German - Published: 2026-05-19 - Updated: 2026-05-19 - Topic: AI Agent Workflows - Agent topics: context-engineering, agent-evals - Tags: AI Agents, Freelancing, Client Work, Automation, Workflow Design - Description: Ein praktischer Workflow für Freelancer und kleine Teams: ein isolierter Projekt-Agent, ein Preview-Rhythmus und ein täglicher Standup gegen Kontextverlust. - Summary: Der nützliche Move ist nicht ein Mega-Assistent für alle Kunden. Gib jedem Kundenprojekt einen kleinen, isolierten Agenten mit eigener Erinnerung, Aufgabenliste, Preview-URL-Gewohnheit und langweiligem Daily Standup. - FAQs: - Q: Was ist ein Kundenprojekt-Agent? A: Ein enger Agent für genau ein Projekt. Er hält Brand Notes, offene Aufgaben, Preview-Links, Entscheidungen und Freigaberegeln getrennt von allen anderen Kunden. - Q: Sollte er Live-Websites automatisch ändern? A: Nein. Die sichere Version arbeitet preview-first: Branch oder Preview erstellen, Änderung zusammenfassen, Freigabe einholen und erst dann manuell oder über einen freigegebenen Release-Pfad shippen. - Q: Was ist der einfachste erste Workflow? A: Starte mit einem read-only Daily Standup: shipped, pending, blocked, wartet auf Kunde, Risiken und die nächsten drei sicheren Aktionen. ### Prompt Decomposition: So zerlegst du KI-Aufgaben richtig - URL: https://huecki.com/blog/prompting-2026-decomposition-skills-evals/ - Markdown URL: https://huecki.com/blog/prompting-2026-decomposition-skills-evals.md - Language: German - Published: 2026-05-18 - Updated: 2026-05-18 - Topic: AI-first Engineering - Agent topics: context-engineering, agent-evals, llm-native-engineering - Tags: Prompt Engineering, Decomposition, AI Agents, Skills, Developer Workflow - Description: Die praktische Fortsetzung zu Context Engineering: Wann Entwickler Aufgaben direkt prompten, zerlegen, als Pipeline bauen oder in Skills auslagern sollten. - Summary: Nach Context Engineering kommt Decomposition: Entwickler sollten nicht alles in einen Prompt stopfen, sondern Aufgaben in direkte Prompts, Subtasks, Pipelines, Agent-Loops oder Skills zerlegen. - FAQs: - Q: Was ist Prompt Decomposition? A: Prompt Decomposition bedeutet, eine große KI-Aufgabe bewusst in kleinere Subtasks, Entscheidungsoptionen, Pipelines oder Skills zu zerlegen, statt alles in einen Mega-Prompt zu schreiben. - Q: Ist Chain-of-Thought noch sinnvoll? A: Die Idee der Zerlegung bleibt sinnvoll, aber der alte Universal-Tipp 'think step by step' ist zu grob. Moderne Reasoning-Modelle brauchen oft eher Ziel, Constraints und Erfolgskriterien; schwächere Modelle profitieren stärker von expliziten Schritten. - Q: Wann sollte ich einen Skill statt eines Prompts schreiben? A: Wenn dieselbe Zerlegung immer wieder vorkommt — zum Beispiel Review, Debugging, Release oder Research — ist ein Skill wartbarer als ein längerer Prompt. ### LLM-native Entwickler brauchen mehr als gute Prompts - URL: https://huecki.com/blog/llm-native-entwickler-operational-maturity/ - Markdown URL: https://huecki.com/blog/llm-native-entwickler-operational-maturity.md - Language: German - Published: 2026-05-15 - Updated: 2026-05-15 - Topic: AI-first Engineering - Agent topics: agent-harnesses, context-engineering, agent-evals, llm-native-engineering - Tags: AI Engineering, LLM, Softwarearchitektur, Agents, Developer Workflow - Description: Eine praktische Notiz für moderne AI-Entwicklung: LLM-native Entwickler brauchen Datenlebenszyklus, Model Ops, Evals, Incident Playbooks, Human-AI UX und Coding-Agent-Harnesses. - Summary: Die nächste Entwicklerfähigkeit ist nicht der cleverste Prompt. Es ist das Betriebssystem um LLMs herum: Datenqualität, Model-Versioning, Evals, Guardrails, Incident Response, Review-UX und Repo-Anweisungen, denen Agents wirklich folgen können. - FAQs: - Q: Was ist ein LLM-native Entwickler? A: Ein Entwickler, der LLM-Verhalten gut genug versteht, um zuverlässige Software darum herum zu bauen: Kontext, Tools, Schemas, Evals, Observability, Security und menschliches Review. - Q: Ist Prompt Engineering noch wichtig? A: Ja, aber es ist nur ein Teil. Wichtiger ist Context Engineering plus der Harness um das Modell: Validierung, Tools, Evals, Fallbacks und Betriebsprozesse. - Q: Was übersehen Teams bei Coding Agents am häufigsten? A: Sie fokussieren sich auf Generierungsgeschwindigkeit und investieren zu wenig in Repo-Anweisungen, Skill-Dateien, Tool-Permissions, Evals, Review-Workflows und Incident Playbooks. ### Sprachnachrichten sind das beste Interface für kleine Agentenjobs - URL: https://huecki.com/blog/sprachnachrichten-agenten-interface/ - Markdown URL: https://huecki.com/blog/sprachnachrichten-agenten-interface.md - Language: German - Published: 2026-05-15 - Updated: 2026-05-15 - Topic: Personal AI Workflows - Agent topics: context-engineering - Tags: AI Agents, Voice Interface, Automation, Open Source, Personal AI - Description: Ein praktischer Workflow für Voice Notes als Agenten-Fernbedienung: lokal transkribieren, sicher routen, kurz antworten — ohne den ganzen Arbeitstag per Sprache steuern zu wollen. - Summary: Voice ist nicht gut für alles. Aber für kleine Agentenjobs ist es brutal praktisch: unterwegs eine Aufgabe diktieren, lokal transkribieren, vom bestehenden Agenten ausführen lassen und nur eine kurze Antwort zurückbekommen. - FAQs: - Q: Soll ich meinen ganzen Arbeitstag per Sprache steuern? A: Nein. Voice lohnt sich vor allem für kleine, klar begrenzte Agentenjobs: Statuschecks, Ideencapture, Triage, Erinnerungen und kurze Entscheidungen. - Q: Brauche ich dafür bezahlte Voice-APIs? A: Nicht zwingend. Ein praktischer Stack ist lokale Transkription mit faster-whisper, ein vorhandener Agenten-Workflow und eine einfache TTS-Antwort, zum Beispiel über Edge TTS. - Q: Wann ist Text besser als Voice? A: Bei Code, Logs, langen Spezifikationen, sensiblen Freigaben und allem, was exakte Formulierungen oder Review braucht. ### Prompting ist tot. Context zählt. - URL: https://huecki.com/blog/prompting-2026-context-engineering/ - Markdown URL: https://huecki.com/blog/prompting-2026-context-engineering.md - Language: German - Published: 2026-05-12 - Updated: 2026-05-12 - Topic: AI-first Engineering - Agent topics: context-engineering, agent-evals, llm-native-engineering - Tags: Prompt Engineering, Context Engineering, AI Agents, KI-Workflows - Description: Moderne Prompts sind keine Zaubersprüche mehr. Gute KI-Workflows bestehen aus Kontext, Tools, Schemas und Evals. - Summary: 2026 geht es nicht mehr um den einen magischen Prompt. Der bessere Ansatz: Kontext wählen, Tools und Schemas definieren, Agent-Regeln setzen und mit Evals prüfen. - FAQs: - Q: Ist Prompt Engineering 2026 wirklich tot? A: Nein, aber es ist erwachsen geworden. Der Fokus verschiebt sich von cleveren Formulierungen zu Context Engineering, Tool-Design, strukturierten Outputs und Evals. - Q: Was ist Context Engineering? A: Context Engineering bedeutet, bewusst zu entscheiden, welche Informationen, Tools, Beispiele, Erinnerungen und Regeln ins Modellfenster gehören — und welche nicht. - Q: Was ist der schnellste praktische Einstieg? A: Starte mit einem klaren Task Contract: Rolle, Aufgabe, Kontext, Constraints, Output-Format, Erfolgskriterien und Verhalten bei Unsicherheit. ### Hermes Agent: Self-Review statt One-Shot - URL: https://huecki.com/blog/hermes-selbstverbessernder-agent/ - Markdown URL: https://huecki.com/blog/hermes-selbstverbessernder-agent.md - Language: German - Published: 2026-05-11 - Updated: 2026-05-12 - Topic: KI-Agenten-Workflows - Agent topics: context-engineering, agent-evals - Tags: Hermes Agent, KI-Agenten, Self-Improvement, Nous Research - Description: Kurz erklärt: wie Hermes Agent Aufgaben ausführt, die eigene Arbeit bewertet und Skills schneller, günstiger und stabiler macht. - Summary: Hermes wird interessant, wenn ein Agent nicht nur liefert, sondern die eigene Arbeit reviewed: ausführen, messen, kritisieren, Skill umbauen, nochmal laufen lassen. Der Nutzen entsteht vor allem bei wiederholbaren Workflows. - FAQs: - Q: Was bedeutet Self-Improvement bei Hermes Agent? A: Hermes kann abgeschlossene Aufgaben bewerten, Ineffizienzen erkennen und Skills oder Prompts für den nächsten Lauf verbessern. - Q: Brauche ich eine spezielle Konfiguration? A: Nein. Der Loop nutzt das Skill-System: Aufgabe ausführen, Review anfordern, Skill umschreiben lassen, erneut testen. - Q: Wann lohnt es sich? A: Wenn ein Workflow regelmäßig läuft. Bei Einmalaufgaben frisst der Review oft mehr Token als er spart. ### AI-first Architektur: schneller entscheiden, sauber bleiben - URL: https://huecki.com/blog/ki-first-softwarearchitektur/ - Markdown URL: https://huecki.com/blog/ki-first-softwarearchitektur.md - Language: German - Published: 2026-04-29 - Updated: 2026-05-12 - Topic: AI-first Engineering - Agent topics: context-engineering, agent-evals, llm-native-engineering - Tags: KI, Softwarearchitektur, GEO, Engineering - Description: Ein kurzer, visueller Workflow für Architekturentscheidungen mit KI: Kontext, Optionen, Review, ADR. Weniger Bla bla, mehr Struktur. - Summary: AI-first Architektur heißt nicht: Modell entscheidet. Es heißt: KI erzeugt Optionen, findet Risiken, verdichtet Kontext — das Team entscheidet und dokumentiert nachvollziehbar. - FAQs: - Q: Was bedeutet AI-first in der Softwarearchitektur? A: KI wird systematisch für Analyse, Varianten, Review und Dokumentation genutzt. Die Verantwortung bleibt beim Team. - Q: Hilft AI-first auch bei SEO und GEO? A: Ja. Klare Definitionen, kurze Antworten, Quellen und strukturierte Entitäten sind leichter zitierbar. ## Tool Catalog ### Architecture Diagram MCP - URL: https://huecki.com/tools/architecture-diagram-mcp/ - Markdown URL: https://huecki.com/tools/architecture-diagram-mcp.md - Language: German - Published: 2026-06-22 - Updated: 2026-06-22 - Category: MCP - Status: Experimental - Agent topics: llm-native-engineering - Tags: MCP, Architecture, Diagrams, Agentic Platform - Description: Ein MCP-Server, der strukturierte Architektur-Briefs in eigenständige HTML-Diagramme und klickbare Erklärseiten übersetzt. - Summary: Architecture Diagram MCP erzeugt browserfähige Architekturartefakte aus Agent-Briefs. Es ist für Plattformkarten, Stakeholder-Erklärungen und reproduzierbare Diagramm-Outputs gebaut. ### Architecture Diagram MCP - URL: https://huecki.com/en/tools/architecture-diagram-mcp-en/ - Markdown URL: https://huecki.com/en/tools/architecture-diagram-mcp-en.md - Language: English - Published: 2026-06-22 - Updated: 2026-06-22 - Category: MCP - Status: Experimental - Agent topics: llm-native-engineering - Tags: MCP, Architecture, Diagrams, Agentic Platform - Description: An MCP server that turns structured architecture briefs into standalone HTML diagrams and clickable explainer pages. - Summary: Architecture Diagram MCP creates browser-ready architecture artifacts from agent briefs. It is built for platform maps, stakeholder explainers, and reproducible diagram outputs. ### Company Researcher - URL: https://huecki.com/tools/company-researcher/ - Markdown URL: https://huecki.com/tools/company-researcher.md - Language: German - Published: 2026-06-22 - Updated: 2026-06-22 - Category: Tool - Status: Experimental - Agent topics: tool - Tags: Company Research, Bundesanzeiger, OpenRouter, Next.js - Description: Eine gehostete Company-Research-App für deutsche Unternehmen mit Deep-Research-Flow, Bundesanzeiger-Daten und OpenRouter-Runtime. - Summary: Company Researcher ist die produktive Oberfläche für schnelle Firmenrecherche: Unternehmensname eingeben, Research-Flow starten, Finanzdaten einsammeln und einen lesbaren Report erzeugen. ### Company Researcher - URL: https://huecki.com/en/tools/company-researcher-en/ - Markdown URL: https://huecki.com/en/tools/company-researcher-en.md - Language: English - Published: 2026-06-22 - Updated: 2026-06-22 - Category: Tool - Status: Experimental - Agent topics: tool - Tags: Company Research, Bundesanzeiger, OpenRouter, Next.js - Description: A hosted company-research app for German companies with a deep-research flow, Bundesanzeiger data, and OpenRouter runtime. - Summary: Company Researcher is the production surface for quick company research: enter a company name, run the research flow, collect financial signals, and produce a readable report. ### Presentation Maker MCP - URL: https://huecki.com/tools/presentation-maker-mcp/ - Markdown URL: https://huecki.com/tools/presentation-maker-mcp.md - Language: German - Published: 2026-06-22 - Updated: 2026-06-22 - Category: MCP - Status: Experimental - Agent topics: mcp - Tags: MCP, Presentations, HTML Decks, Agentic Platform - Description: Ein MCP-Server für selbstlaufende Lern- und Stakeholder-Decks als eigenständige HTML-Artefakte. - Summary: Presentation Maker MCP baut browserfähige Decks aus Briefings. Es verbindet klare Slide-Struktur, Speaker Notes, Tastaturnavigation und exportierbare HTML-Artefakte. ### Presentation Maker MCP - URL: https://huecki.com/en/tools/presentation-maker-mcp-en/ - Markdown URL: https://huecki.com/en/tools/presentation-maker-mcp-en.md - Language: English - Published: 2026-06-22 - Updated: 2026-06-22 - Category: MCP - Status: Experimental - Agent topics: mcp - Tags: MCP, Presentations, HTML Decks, Agentic Platform - Description: An MCP server for self-paced learning and stakeholder decks as standalone HTML artifacts. - Summary: Presentation Maker MCP builds browser-ready decks from briefs. It combines slide structure, speaker notes, keyboard navigation, and exportable HTML artifacts. ### Agent Save File Starter - URL: https://huecki.com/tools/agent-save-file-starter/ - Markdown URL: https://huecki.com/tools/agent-save-file-starter.md - Language: German - Published: 2026-06-16 - Updated: 2026-06-16 - Category: Template - Status: Experimental - Agent topics: agent-harnesses, context-engineering - Tags: Coding Agents, Agent Memory, Context Engineering, AGENTS.md - Description: Ein kompaktes Starter-Template für Coding-Agent-Projekte: Arbeitsregeln, Runbook, Entscheidungen und bekannte Fehler an einem Ort. - Summary: Ein leichtgewichtiges Projektgerüst für Agent-Kontextdateien. Es trennt harte Regeln, sichere Commands, gültige Entscheidungen und alte Hinweise, damit Agents nicht aus Chat-Müll arbeiten. ### Agent Save File Starter - URL: https://huecki.com/en/tools/agent-save-file-starter-en/ - Markdown URL: https://huecki.com/en/tools/agent-save-file-starter-en.md - Language: English - Published: 2026-06-16 - Updated: 2026-06-16 - Category: Template - Status: Experimental - Agent topics: agent-harnesses, context-engineering - Tags: Coding Agents, Agent Memory, Context Engineering, AGENTS.md - Description: A compact starter template for coding-agent projects: working rules, runbook, decisions, and known issues in one place. - Summary: A lightweight project structure for agent context files. It separates hard rules, safe commands, active decisions, and archived notes so agents do not work from chat sludge. ### DeepResearch Skill - URL: https://huecki.com/tools/deepresearch-skill/ - Markdown URL: https://huecki.com/tools/deepresearch-skill.md - Language: German - Published: 2026-06-16 - Updated: 2026-06-16 - Category: Skill - Status: Stable - Agent topics: context-engineering - Tags: Research, Agent Skills, Evidence, Sources - Description: Ein Agent-Skill für belastbare Recherche mit Plan, Quellenliste, Evidenzextraktion, Gegenprüfung und zitierfähigem Report. - Summary: DeepResearch zwingt Agenten aus dem schnellen Suchmaschinen-Summary-Modus heraus. Der Skill schreibt Recherche-Artefakte, trennt Primär- von Sekundärquellen und verlangt URL-gestützte Evidenz vor der Synthese. ### DeepResearch Skill - URL: https://huecki.com/en/tools/deepresearch-skill-en/ - Markdown URL: https://huecki.com/en/tools/deepresearch-skill-en.md - Language: English - Published: 2026-06-16 - Updated: 2026-06-16 - Category: Skill - Status: Stable - Agent topics: context-engineering - Tags: Research, Agent Skills, Evidence, Sources - Description: An agent skill for evidence-backed research with a plan, source list, evidence extraction, cross-checking, and a cited report. - Summary: DeepResearch pushes agents out of quick search-summary mode. The skill writes research artifacts, separates primary from secondary sources, and requires URL-backed evidence before synthesis. ### Is This Agentic Change Good? - URL: https://huecki.com/tools/is-this-agentic-change-good/ - Markdown URL: https://huecki.com/tools/is-this-agentic-change-good.md - Language: German - Published: 2026-06-16 - Updated: 2026-06-16 - Category: Skill - Status: Experimental - Agent topics: agent-harnesses, agent-security, context-engineering, agent-evals - Tags: Agent Skills, Review, AGENTS.md, Safety - Description: Ein Read-only Review-Skill für Änderungen an Agent-Setup, Skills, AGENTS.md, Runtime-Kontext und Sicherheitsgrenzen. - Summary: Dieser Skill prüft Branches, die zukünftiges Agent-Verhalten verändern. Er sammelt lokale Git-Evidenz, bewertet Skill-Kollisionen, Kontextbudget, Sicherheitsrisiken und Runtime-Sichtbarkeit, bevor ein Merge empfohlen wird. ### Is This Agentic Change Good? - URL: https://huecki.com/en/tools/is-this-agentic-change-good-en/ - Markdown URL: https://huecki.com/en/tools/is-this-agentic-change-good-en.md - Language: English - Published: 2026-06-16 - Updated: 2026-06-16 - Category: Skill - Status: Experimental - Agent topics: agent-harnesses, agent-security, context-engineering, agent-evals - Tags: Agent Skills, Review, AGENTS.md, Safety - Description: A read-only review skill for changes to agent setup, skills, AGENTS.md, runtime context, and safety boundaries. - Summary: This skill reviews branches that change future agent behavior. It collects local git evidence and judges skill collisions, context budget, safety risks, and runtime visibility before recommending a merge. ## Buildprint Catalog ### Auth, Teams & RBAC OS - URL: https://huecki.com/buildprints/auth-teams-rbac-os/ - Category: Feature - Creator: Agent Buildprint - Difficulty: Advanced - Stack: Auth, Teams, RBAC, Multi-tenant SaaS, Audit logs - Summary: Secure team accounts, memberships, roles, permissions, invites, audit logs, and tenant isolation around an existing auth provider. - Promise: Add Auth, Teams & RBAC without letting an agent rip out existing auth, fake frontend-only permissions, or miss tenant isolation. - Includes: Auth forensics; Tenant boundary map; Permission engine; Invite lifecycle; Audit log; Offline TypeScript proof; Target-app conformance kit - Key risks: Frontend-only authorization; Cross-tenant data leaks; Self-escalation or last-owner loss - Validation checks: Phase 00 forensics must complete first; Permission engine denies by default; Every team-scoped route has direct API auth tests; Invites and role changes emit redacted audit events; Offline proof harness is included and testable; Target-app conformance suite must pass against a real adapter or record blockers - Manifest: https://agent-buildprint.com/buildprints/auth-teams-rbac-os/package.json - GitHub: https://github.com/DomEscobar/agent-buildprint/tree/main/buildprints/auth-teams-rbac-os ### OpenClaw AI Influencer OS - URL: https://huecki.com/buildprints/ai-influencer-os/ - Category: Product OS - Creator: Agent Buildprint - Difficulty: Advanced - Stack: OpenClaw, Telegram, Wavespeed, OpenRouter, Docker - Summary: Persona memory, social drafting, image generation, approval gates, and secured browser publishing handoff for an AI influencer runtime. - Promise: Bootstrap a full OpenClaw-based AI Influencer OS without letting an agent collapse it into a generic chatbot or scheduler. - Includes: Persona + memory state; Wavespeed image workflow; Grounded social drafts; Manager audit; Secured browser handoff - Key risks: Auto-publishing by default; Unsafe public/private media handling; Unauthenticated noVNC exposure - Validation checks: Mock tests make no external API calls; Media policy gates return structured blocks; Publishing defaults to approval/manual mode; Runtime command and files are present - Manifest: https://agent-buildprint.com/buildprints/ai-influencer-os/package.json - GitHub: https://github.com/DomEscobar/agent-buildprint/tree/main/buildprints/ai-influencer-os ### Automated AI Blog OS - URL: https://huecki.com/buildprints/automated-ai-blog-os/ - Category: Product OS - Creator: Agent Buildprint - Difficulty: Advanced - Stack: Astro/MDX, Markdown, SEO, Approval queue, Scheduler - Summary: Research scanning, idea scoring, content memory, draft generation, SEO validation, approval queue, and scheduled publishing. - Promise: Give a coding agent the full operating contract for a useful AI blog pipeline that does not skip SEO, approval, or stale-content audits. - Includes: Research scanner; Idea scorer; Content memory; SEO validator; Approval queue - Key risks: Publishing without approval; Unsupported claims; SEO/build checks skipped - Validation checks: Drafts cite source/evidence state; SEO/build validator runs before publish; Approval gate blocks external publishing; Manager audit catches stale work - Manifest: https://agent-buildprint.com/buildprints/automated-ai-blog-os/package.json - GitHub: https://github.com/DomEscobar/agent-buildprint/tree/main/buildprints/automated-ai-blog-os ### Buildprint Mapper OS - URL: https://huecki.com/buildprints/buildprint-mapper-os/ - Category: Quality - Creator: Agent Buildprint - Difficulty: Advanced - Stack: Any repo, Phase-flow replay, Evidence ledger, Fresh-agent evals - Summary: Map an existing repo into an executable Buildprint packet with phase-flow replay, schema-valid evidence, review contracts, and fresh-agent isolation. - Promise: Turn a real codebase into a source-independent execution contract so agents build in bounded phases, prove claims honestly, and hand off without source-repo access. - Includes: Source census; Scope selection; Executable packet spine; Phase-flow constitution; Runtime evidence schema; Architecture/UX/QA review loop; Fresh-agent replay scorer - Key risks: Secret leakage; Scope shrink; Synthetic proof overclaimed; Provider/browser blockers hidden as success - Validation checks: Every phase starts with implementation grammar; Runtime evidence rows are schema-valid; Blocked/synthetic evidence cannot upgrade claims; No-fake scans require real artifacts; Architecture/UX/QA reviews answer required headings; Fresh-agent replay and outcome judge pass or name gaps - Manifest: https://agent-buildprint.com/buildprints/buildprint-mapper-os/package.json - GitHub: https://github.com/DomEscobar/agent-buildprint/tree/main/buildprints/buildprint-mapper-os ### Complete Agent Skills Evaluation OS - URL: https://huecki.com/buildprints/complete-agent-skills-evaluation-os/ - Category: Quality - Creator: Agent Buildprint - Difficulty: Advanced - Stack: Node.js, Fixtures, Eval harness, CI - Summary: Offline deterministic evals for skills, agent setup contracts, commands, hooks, routers, subagents, and workflow rules. - Promise: Prove whether an agent setup is installed, discoverable, useful, safe, reproducible, and worth its context cost. - Includes: Setup snapshot; Static lint; Skill unit evals; Transcript invariants; Scorecard - Key risks: Live-provider false positives; Undiscoverable skills; Unsafe multi-agent execution - Validation checks: Offline fixtures only by default; Scorecard produces evidence; Process invariants are asserted; Live adapters require separate acceptance - Manifest: https://agent-buildprint.com/buildprints/complete-agent-skills-evaluation-os/package.json - GitHub: https://github.com/DomEscobar/agent-buildprint/tree/main/buildprints/complete-agent-skills-evaluation-os ### Perfect RAG / Retrieval OS - URL: https://huecki.com/buildprints/perfect-rag-retrieval-os/ - Category: Workflow OS - Creator: Agent Buildprint - Difficulty: Advanced - Stack: Mapper OS v5, Hybrid retrieval, Reranking, Citations, RAG evals - Summary: Executable Mapper OS phase-flow packet for building a serious RAG/Retrieval OS with corpus contracts, ingestion, chunking, hybrid retrieval, permission filtering, reranking, grounded citations, refusal behavior, traces, and eval gates. - Promise: A fresh agent can run the packet from BUILDPRINT.md through phase-flow to implement a permission-safe, citation-grounded retrieval system without reducing the product to vector search plus a prompt. - Includes: BUILDPRINT.md canonical start; 01-questions.md alignment gate; 02-project-setup.md architecture, team, authority, handoff, AGENTS.md, quality, safety, and phase-start contract; blueprint.yaml executable-blueprint v5 machine contract; 03-phases/phase-flow.md orchestration protocol; Four implementation phases with proof gates; 04-evaluation.md retrieval, answer, operational, blocker, and claim-upgrade rules; 05-evidence seed ledger and runtime evidence schema - Key risks: Vector-only false confidence; Hallucinated uncited answers; Permission leakage; Eval-free quality drift; Reranker latency/cost creep; Live provider claims from deterministic proof; Advanced-tech hype without measured gain - Validation checks: Mapper OS selected-output structural check passes; Packet uses BUILDPRINT.md as canonical start; Every phase starts with Mapper OS phase-flow entry grammar; Runtime evidence is separated from packaged seed evidence; Evidence schema blocks missing, blocked, synthetic, partial, sandbox, network-limited, and credential-limited rows from upgrading claims; Publication copy reflects phase-flow methodology rather than legacy proof-only package - Manifest: https://agent-buildprint.com/buildprints/perfect-rag-retrieval-os/package.json - GitHub: https://github.com/DomEscobar/agent-buildprint/tree/main/buildprints/perfect-rag-retrieval-os ### Portable AI Shorts Production Studio - URL: https://huecki.com/buildprints/portable-ai-shorts-production-studio/ - Category: Mapped Project - Creator: Agent Buildprint - Difficulty: Advanced - Stack: Product analysis, UGC scripts, Provider adapters, Async jobs, Media composition, Gallery and publish handoff - Summary: Mapper OS phase-flow Buildprint for a portable AI shorts production studio with product URL/manual input, UGC scripts, deterministic provider adapters, pollable jobs, 1080x1920 MP4 fixture media, private gallery, consent-gated publish handoff, and evidence-honest validation. - Promise: A Mapper OS executable packet that preserves the full AI shorts production workflow while keeping provider, media, browser, persistence, gallery, publishing, and security claims tied to phase proof and runtime evidence. - Includes: BUILDPRINT.md canonical start; 01-questions.md AI best-judgment alignment gate; 02-project-setup.md with architecture, team model, AGENTS.md plan, safety, gates, and phase start gate; blueprint.yaml executable-blueprint v5 machine contract; 03-phases/phase-flow.md orchestration protocol; Five implementation phase files; 04-evaluation.md claim upgrade rules; 05-evidence/evidence-ledger.schema.json honest evidence schema; Seed-only 05-evidence/evidence-ledger.jsonl; Compatibility docs for specification, contracts, plan, test matrix, validation, and acceptance - Key risks: Accidentally implying OpenShorts clone or drop-in replacement parity; Provider/API/live media success overclaiming; Rendering-quality parity overclaiming; Social platform publishing reliability overclaiming; Public gallery exposure without consent and access controls; User likeness, uploaded media, URL egress, and copyright under-specification; In-memory proof storage being misreported as production durability - Validation checks: Mapper OS selected-output spine exists and starts from BUILDPRINT.md; Every phase starts with the required Mapper OS phase implementation heading; Every phase requires phase-flow, .buildprint/next-agent.md, and current project AGENTS.md; 02-project-setup.md defines architecture, team operating model, execution authority, delegation, AGENTS.md plan, quality gates, safety, assumptions, and phase start gate; Packaged evidence ledger is seed-only and runtime evidence routes to .buildprint/evidence/evidence-ledger.jsonl; Evidence schema requires artifact_id, type, phase_id, status, source, proves, proof_type, provider_mode, and upgrades_claim; Blocked, missing, synthetic, partial, sandbox-limited, network-limited, credential-limited, or dry-run proof cannot upgrade claims; Browser, provider, media, persistence, billing-free publishing handoff, security, memory/retrieval-adjacent context, and operational boundaries are preserved as explicit contracts - Manifest: https://agent-buildprint.com/buildprints/portable-ai-shorts-production-studio/package.json - GitHub: https://github.com/DomEscobar/agent-buildprint/tree/main/buildprints/portable-ai-shorts-production-studio ### Portable Durable Agent Graph Runtime - URL: https://huecki.com/buildprints/portable-durable-agent-graph-runtime/ - Category: Agent - Creator: Agent Buildprint - Difficulty: Advanced - Stack: TypeScript, Graph runtime, Checkpoints, Streams, Interrupts - Summary: Dependency-light runtime for typed state, graph nodes, conditional edges, checkpointing, streaming, interrupts, and resume. - Promise: Create a portable LangGraph-like mental model without runtime lock-in or hidden framework dependencies. - Includes: Typed state schema; Graph builder; Checkpoint saver; Interrupt/resume; Streaming invoke - Key risks: Fake durability; Unclear state reducers; Side effects without checkpoints - Validation checks: Compile validation catches bad routes; Checkpoint interfaces are explicit; Interrupt resume is tested; No heavyweight graph dependency required - Manifest: https://agent-buildprint.com/buildprints/portable-durable-agent-graph-runtime/package.json - GitHub: https://github.com/DomEscobar/agent-buildprint/tree/main/buildprints/portable-durable-agent-graph-runtime ### Portable Novel-to-Storyboard Pipeline - URL: https://huecki.com/buildprints/portable-novel-storyboard-pipeline/ - Category: Product OS - Creator: Agent Buildprint - Difficulty: Advanced - Stack: Story pipeline, Mock providers, Storyboard XML, Canvas QA - Summary: Import chapters, extract events, adapt scripts, create assets, generate storyboard panels, validate XML, and preview without fake success states. - Promise: Build a deterministic novel-to-storyboard pipeline that agents can implement end-to-end before expanding into live providers. - Includes: Chapter import; Event extraction; ScriptAgent stages; Asset extraction; Storyboard validation - Key risks: Malformed XML corrupting state; Placeholder controls; Live-provider claims without gates - Validation checks: Default CI uses mock/no-network providers; 3 fixture chapters complete successfully; Malformed outputs are rejected safely; Unimplemented capabilities are excluded - Manifest: https://agent-buildprint.com/buildprints/portable-novel-storyboard-pipeline/package.json - GitHub: https://github.com/DomEscobar/agent-buildprint/tree/main/buildprints/portable-novel-storyboard-pipeline ### Portable Personal Agent Chat OS - URL: https://huecki.com/buildprints/portable-personal-agent-chat-os/ - Category: Mapped Project - Creator: Agent Buildprint - Difficulty: Advanced - Stack: Streaming chat, Provider router, Tools / Skills / MCP, Memory and compaction, Subagents, Telemetry, WebUI/API workbench - Summary: Mapper OS phase-flow packet for building a clean-room, self-hosted personal agent chatbot OS with streaming chat, provider routing, tools, skills, MCP, memory, subagents, telemetry, and WebUI/API workbench surfaces. - Promise: A phase-flow Buildprint that lets a downstream agent implement a portable personal agent chatbot OS while keeping deterministic proof separate from live/external claims. - Includes: BUILDPRINT.md canonical entry; 01-questions.md setup questions; 02-project-setup.md architecture and operating contract; blueprint.yaml machine contract; 03-phases/phase-index.yaml phase index; 03-phases/phase-flow.md orchestration protocol; Phase files for storage, runtime, tools/MCP, memory/team/telemetry, safety, and WebUI/API; 04-evaluation.md evidence honesty gates; 05-evidence/evidence-ledger.schema.json; Seed-only evidence ledger - Key risks: Overclaiming full Emperor Agent clone parity; Unsafe shell/filesystem/network/browser tools; Provider API drift; Context truncation losing user instructions; Skill injection bloat; MCP timeout/security failures; In-memory state being mistaken for durable persistence; Telemetry hidden from UI; Hosted auth, billing, publishing, media, or retrieval claims without proof - Validation checks: Mapper selected-output structural check passes; Executable packet starts from BUILDPRINT.md; 02-project-setup.md defines architecture, team model, execution authority, handoffs, AGENTS.md plan, quality gates, safety, assumptions, and phase start gate; Every phase starts with the required implementation heading and routes through phase-flow artifacts; Packaged evidence ledger is seed-only; Runtime evidence belongs only in .buildprint/evidence/evidence-ledger.jsonl; Evidence schema blocks blocked/missing/synthetic/partial rows from upgrading claims; Publication copy prompt names the executable read order; Legacy document sludge removed or reduced to compatibility spine files - Manifest: https://agent-buildprint.com/buildprints/portable-personal-agent-chat-os/package.json - GitHub: https://github.com/DomEscobar/agent-buildprint/tree/main/buildprints/portable-personal-agent-chat-os ### Stripe Billing Extension - URL: https://huecki.com/buildprints/stripe-billing-extension/ - Category: Integration - Creator: Agent Buildprint - Difficulty: Medium - Stack: TypeScript, Stripe, Webhooks, SaaS - Summary: Stripe Checkout, customer portal, verified webhooks, subscription state, entitlement guards, billing UI, and lifecycle tests. - Promise: Add SaaS billing to an existing product without missing webhook signatures, entitlement checks, or subscription lifecycle states. - Includes: Checkout sessions; Customer portal; Webhook verification; Subscription state; Entitlement guards - Key risks: Webhook replay bugs; Payment state drift; Premium access without active subscription - Validation checks: Webhook signatures are verified; Portal access requires auth; Entitlements check server state; Lifecycle tests cover updates/cancellations - Manifest: https://agent-buildprint.com/buildprints/stripe-billing-extension/package.json - GitHub: https://github.com/DomEscobar/agent-buildprint/tree/main/buildprints/stripe-billing-extension ### Superpowers Skill Methodology Harness - URL: https://huecki.com/buildprints/superpowers-skill-methodology-harness/ - Category: Quality - Creator: Agent Buildprint - Difficulty: Advanced - Stack: Node.js, Agent skills, Transcript evals, Methodology - Summary: Portable harness that turns engineering process rules into executable agent behavior and transcript-backed verification. - Promise: Make coding agents load relevant skills, design before implementation, use TDD, delegate safely, and block completion without evidence. - Includes: Skill lookup discipline; Design approval gate; TDD gate; Subagent packets; Transcript evals - Key risks: Skipping process gates; Copying upstream text; Claiming official compatibility - Validation checks: Skills load before action; Plans include exact paths/tests; Review evidence blocks completion; Transcript evals catch process drift - Manifest: https://agent-buildprint.com/buildprints/superpowers-skill-methodology-harness/package.json - GitHub: https://github.com/DomEscobar/agent-buildprint/tree/main/buildprints/superpowers-skill-methodology-harness