RESEARCH BRIEF 15 / 30
Evaluation harnesses for autonomous agents with observable outcomes
Research question
What evidence distinguishes a running agent from an automation that merely reports itself as active?
Proposed research protocol
Create a test suite of task instances with input, authorized tools, budget, allowed side effects, expected artifacts and failure boundaries. Separate mock-tool unit tests from staged end-to-end tests and real production traces. Record each agent invocation with job ID, timestamps, tool results, retries, cost and operator approvals. Use signed or append-only logs for the critical record.
Analytical framework and study design
Define success only when an external effect can be independently inspected: content actually appears at the target URL, an authorized file was correctly updated, or a report includes traceable evidence. Add adversarial tasks involving stale credentials, tool outages, permission changes, conflicting instructions and false tool success messages. Compare model variants on matched task instances.
Validation, reporting and acceptance evidence
Report verified success fraction, unauthorized action rate, 95th percentile latency, recovery rate, and human escalation frequency. Dashboard charts must be driven by real event tables and clearly distinguish planned, running, failed, completed and verified outcomes.
Limitations and responsible interpretation
An agent can pass offline benchmarks while failing under live dependencies. Never label unobserved business gains as produced by agents.
Methodological references
RESEARCH BRIEF 16 / 30
Safe self-improving systems with bounded authority and rollback
Research question
When an autonomous system proposes changing its own code or configuration, how can an organization prevent cascading production failures?
Proposed research protocol
Implement separation of proposer, tester, reviewer and deployer privileges. Proposed changes become signed artifacts with diff, test results, dependency lockfiles and reversible deployment instructions. Put destructive operations, identity management, purchases and production access outside autonomous default permissions. Require independent review for scope expansion.
Analytical framework and study design
Use canary deployment with strict resource, time and error budgets, and an automatically evaluated rollback predicate. Maintain a known-good version and evaluate each candidate against regression and safety suites; improvements on one metric must not regress essential protections. Treat prompt-injection attempts as untrusted input and test boundary crossings explicitly.
Validation, reporting and acceptance evidence
Track proportion of attempted unauthorized actions denied, regression defects detected before release, canary rollback latency and percentage of changes traceable to human approval. Record who authorized each promotion and why observed evidence warranted the decision.
Limitations and responsible interpretation
Self-modification is not biological evolution, and an assigned generation number is not evidence of meaningful improvement. Safety outcomes need sustained production observation.
Methodological references