
Act as a **senior AI systems architect, agent infrastructure...
Prompt
Act as a **senior AI systems architect, agent infrastructure engineer, technical founder, and product strategist**. I want you to deeply research modern agentic harnesses and then design a production-quality harness from first principles. Do NOT give me a generic explanation. The goal is to understand how excellent agentic harnesses work and produce a concrete blueprint I could actually build. Use current information and research wherever possible. Prefer official documentation, engineering blogs, papers, GitHub repositories, and primary technical sources. Clearly distinguish **FACT, INFERENCE, and RECOMMENDATION**. Cite important claims. --- # 1. WHAT IS AN AGENTIC HARNESS? Establish a precise definition. Explain the differences between: * LLM/model * API * tool-calling agent * agent framework * agent runtime * agentic harness * coding agent * AI IDE * multi-agent system Explain why a harness exists, what it controls, what belongs inside it, and what should NOT belong inside it. Give me a strong mental model of the entire stack. --- # 2. CURRENT LANDSCAPE Research serious systems such as: Claude Code, OpenAI Codex/coding agents, Gemini CLI, OpenCode, Aider, SWE-agent, Cline/Roo Code, Devin, Cursor agents, OpenHands, LangGraph, AutoGen, CrewAI, smolagents, and other relevant systems. For the important ones analyze: * architecture * agent loop * context management * tools * planning * memory * filesystem/terminal * execution * verification * recovery * permissions/security * model routing * subagents * parallelism * observability * evaluation * cost/latency * UX * extensibility For each, identify: **What should be copied / What should be avoided / Why** Do not pretend proprietary internals are known. Separate public facts from inference. --- # 3. DESIGN THE CORE HARNESS Design a concrete production-grade architecture. Cover: ### Runtime * agent loop * state machine * event system * task manager * session manager * execution engine * cancellation/timeouts * retry system * persistence ### Intelligence * planning * task decomposition * replanning * context selection * context compression * reflection * verification * self-correction * model routing * escalation * subagents * parallel execution ### Tools * tool registry * schemas * discovery * selection * validation * execution * permissions * result normalization * retries * caching * parallel calls * plugins/MCP-style tools ### Environment * filesystem * shell * git * code execution * browser/web * APIs * sandboxing * snapshots/checkpoints Explain which components should be deterministic code versus LLM-controlled. --- # 4. THE AGENT LOOP Design the ideal execution loop: USER REQUEST → UNDERSTAND → GATHER CONTEXT → PLAN → EXECUTE → OBSERVE → UPDATE STATE → VERIFY → RECOVER/REPLAN → CONTINUE → FINAL RESULT For every stage explain: * input/output * purpose * failure modes * whether an LLM is needed * how to make it efficient Give pseudocode for the core loop. --- # 5. CONTEXT ENGINEERING Treat context as one of the most important parts of the harness. Design how the system answers: > "What does the model need to know RIGHT NOW?" Cover: * context prioritization * relevance scoring * token budgets * codebase understanding * file selection * dynamic retrieval * context compression * summarization * tool-result compression * stale-context detection * state representation * preventing context pollution * avoiding repeated work Give a practical algorithm/pseudocode. Explain why blindly dumping the repository/history into the context is a bad architecture. --- # 6. PLANNING + EXECUTION Compare: * reactive loops * lightweight planning * hierarchical planning * task graphs/DAGs * plan-and-execute * recursive planning Determine when the harness should: * plan * skip planning * replan * ask the user * delegate * execute immediately Design a practical planning system rather than a "20-step plan" gimmick. --- # 7. ERROR RECOVERY + VERIFICATION Design robust recovery for: * invalid tool calls * wrong assumptions * failed commands * compilation failures * test failures * API failures * timeouts * partial execution * corrupted state * repeated mistakes * infinite loops * getting stuck Include: * retries * alternative strategies * rollback * checkpoints * failure classification * model escalation * human approval Then design verification. For coding tasks consider: * compilation * linting * tests * integration tests * static analysis * git diff inspection * behavioral checks * independent verifier agents Make clear why: **"The model says it worked" ≠ "It actually worked."** --- # 8. MEMORY + STATE Design the state and memory architecture. Distinguish: * conversation history * working memory * task state * project memory * persistent memory * semantic memory * procedural memory * cached context Tell me which are genuinely useful and which are unnecessary complexity. Define the minimum state the harness must maintain to execute a task reliably. --- # 9. SUBAGENTS + MODEL ROUTING Be skeptical of multi-agent systems. Explain when subagents improve results versus merely increasing cost, latency, and complexity. If useful, design: * planner * worker * researcher * reviewer * verifier * specialist Explain delegation, isolation, shared state, contracts, parallelism and failure handling. Then design a model abstraction/routing layer. It should support different providers/models based on: * task difficulty * cost * latency * context requirements * tool capability * reliability Example strategy: FAST/CHEAP MODEL → routine work STRONG MODEL → difficult reasoning SPECIALIST → specific tasks VERIFIER → independent checking --- # 10. EFFICIENCY Explain how to make the harness: **faster + cheaper + more reliable + less token-heavy** Analyze: * prompt/context caching * context reuse * parallel tools * asynchronous execution * model routing * result caching * incremental indexing * batching * streaming * lazy context loading * checkpointing Identify the biggest sources of: * token waste * latency * redundant model calls * redundant tool calls * repeated reasoning * context bloat Give concrete optimization strategies. --- # 11. SECURITY Design a serious security model covering: * shell execution * filesystem access * network * credentials/secrets * arbitrary code * sandboxing * destructive actions * prompt injection * malicious repositories/files * tool poisoning * data exfiltration Design permission levels such as: READ / WRITE / EXECUTE / NETWORK / CREDENTIAL / DESTRUCTIVE Explain what requires user confirmation and what can be autonomous. --- # 12. OBSERVABILITY + EVALUATION Design observability: * logs * events * traces * execution trajectories * token usage * latency * tool statistics * failure tracking * cost Then design a serious evaluation system. Measure: * task success * correctness * reliability * first-attempt success * recovery rate * tool efficiency * token efficiency * cost per successful task * latency * regressions Create benchmark tasks from easy → difficult and explain how trajectories should be compared between harness versions. --- # 13. WHAT NOT TO BUILD Be opinionated. Create: ### BUILD ### MAYBE ### DO NOT BUILD Identify features that are impressive in demos but provide little real value, especially unnecessary: * multi-agent complexity * memory systems * abstractions * vector databases * planning layers * autonomous behavior * UI features Do not optimize for feature count. Optimize for: **TASK SUCCESS × RELIABILITY × SPEED × COST × DEBUGGABILITY** --- # 14. ACTUAL TECHNICAL BLUEPRINT Now stop researching and synthesize one recommended architecture. Give me: 1. ASCII architecture diagram 2. Components 3. Data flow 4. Agent loop 5. State model 6. Context model 7. Tool model 8. Permission model 9. Memory model 10. Verification pipeline 11. Recovery system 12. Model routing 13. Evaluation system 14. Storage 15. Deployment Then give a recommended technology stack and explain alternatives. Provide a clean project structure such as: /core /agent /context /tools /models /runtime /security /storage /evaluation /interface Explain what belongs in each. --- # 15. BUILD ROADMAP Assume a small team or solo developer. Define: ### V0 — minimum useful harness ### V1 — serious usable harness ### V2 — production-grade harness For each give: * exact features * architecture * what to exclude * difficulty * value * biggest risks Then give the **dependency-aware build order**. I want the first ~10 engineering tasks in exact sequence, not vague advice. --- # 16. PRODUCT + BUSINESS Analyze who would actually pay for an agentic harness: * developers * startups * enterprises * engineering teams * AI startups * research teams * automation companies Analyze: * SaaS * self-hosted * licensing * enterprise licensing * source-available * OEM/embedded infrastructure * acquisition * consulting + software If the goal is to build a technically strong project and potentially sell the **product/IP/company outright**, analyze that strategy separately. Explain what makes an agentic harness valuable enough to acquire. --- # 17. COMPETITIVE ADVANTAGE + RISKS Do not use "better AI" as differentiation. Identify genuinely defensible advantages such as: * reliability * execution architecture * context engineering * evaluation * security * cost efficiency * speed * specialized workflows * deployment * observability Then give a brutal risk analysis covering: * foundation models improving * model providers building native harnesses * competitors copying features * API costs changing * reliability problems * security incidents * maintenance burden * weak differentiation * runaway costs For each major risk give: **Probability / Impact / Warning Sign / Mitigation** --- # FINAL SECTION — IF I WERE BUILDING THIS TOMORROW Give me one decisive answer. Assume I want to build a **small, extremely well-engineered agentic harness**, not another bloated framework. Tell me: 1. The exact architecture I should use 2. The 5 most important architectural decisions 3. The 5 things I should NOT build 4. The first 10 engineering tasks 5. The first 5 evaluation benchmarks 6. The first target customer 7. The first compelling product capability 8. The strongest potential competitive advantage 9. The biggest threat to the project 10. What would make an expert engineer look at it and say: **"This is actually a well-designed harness."** Be technically rigorous, practical, skeptical, and opinionated. Do not confuse complexity with sophistication. The goal is not to build the biggest agent system. The goal is to build the **most reliable, efficient, understandable, extensible and commercially valuable harness possible with today's models.**