AI Agents

Much of the early conversation around applied AI focused on prompt engineering: if the output was weak, the prompt needed improvement. Recent work in agent engineering suggests a broader shift. Prompt engineering still matters, yet it now functions as only one layer in a larger system. Context engineering determines what information the model sees, when it sees it, and what gets preserved across work. Harness engineering goes further still: it defines the runtime environment, verification loops, handoff artifacts, decomposition strategy, and coordination structures that allow an agent to work productively across long horizons rather than a single short session. Anthropic’s recent engineering posts trace this progression clearly, from context curation to initializer agents, structured progress files, parallel agent teams, planner-generator-evaluator loops, and decoupled execution architectures. This essay argues that the next generation of AI products will be differentiated less by clever prompts alone than by the systems built around model reasoning (Anthropic Engineering, 2025a; Anthropic Engineering, 2025b; Anthropic Engineering, 2026a; Anthropic Engineering, 2026b; Anthropic Engineering, 2026c). ...

As AI agents move from demo toys to production infrastructure, the question of how they connect to backend services has become a serious architectural decision. There are currently two dominant strategies: exposing capabilities through REST APIs paired with structured skill documents, and exposing capabilities through MCP (Model Context Protocol) servers. The popular framing — that REST is legacy and MCP is the future — oversimplifies the tradeoff. REST APIs, particularly when backed by machine-readable specifications like OpenAPI, offer strong contracts, broad compatibility, and mature tooling. MCP offers agent-native tool discovery, session-aware invocation, and push-based capability updates designed specifically for LLM tool use. Neither subsumes the other. This essay examines the two strategies across three dimensions — contract strength, orchestration control, and adaptability to code changes — and argues that the right choice depends on who your consumers are, what granularity they need, and how much backend volatility you expect them to absorb. ...