New tools for building agents

Original Article ↗ Hacker News Discussion ↗

What is an “agent”?

  • Thread spends substantial time arguing definitions.
  • One camp: “agent” is basically any LLM-backed program acting on a user’s behalf (almost all software).
  • Another: distinguishes workflows (predefined code paths orchestrating tools) from agents (LLMs dynamically choosing tools and steps at runtime).
  • Others reduce it to structured tool-calling/chatbots that turn natural language into backend function calls.
  • Some reference agent-oriented programming: autonomy, own event loop, reacting to environment, not just pure request/response.

Agents SDK, alternatives, and abstractions

  • Many like the new Agents SDK for being simpler and less “bloated” than earlier frameworks; some think it will kill weak agent startups.
  • Others prefer remaining framework-agnostic and recommend PydanticAI, smolagents, or other open-source agent frameworks.
  • Some view most “agent” needs today as simple workflows plus structured outputs, not needing high-level orchestration.

MCP vs OpenAI’s approach

  • Notable absence of first-class Model Context Protocol (MCP) support sparks criticism; seen by some as “anti-developer” and ecosystem-hostile.
  • Defenders say MCP can still be wired in via function calling and bridges; MCP is framed as a protocol for tools/context, not a full agent framework.
  • Some developers love MCP (especially for local tools, DBs, terminals); others find it heavy and over-engineered compared to minimal function-calling.

Pricing and economics (search, file, computer use)

  • Web search pricing (~$25–30 per 1K queries) widely called “absurd” and “not usable at scale,” especially versus Brave or Perplexity.
  • File search and computer-use pricing seen as expensive but less shocking; unclear yet which use cases can justify the costs.
  • Several note that both OpenAI and Google seem to price grounded search much higher than traditional web search.

Responses API, RAG, and Assistants deprecation

  • Responses API is viewed as a cleaner evolution with built‑in RAG, reranking, and “handoff” logic; some surprised by simplistic default chunking.
  • Assistants API is slated to sunset mid‑2026; OpenAI promises feature parity (threads, code interpreter, async) and a 12‑month migration window once ready.
  • Developers running significant traffic on Assistants wonder when to migrate; guidance is “no rush yet.”

Vendor lock-in, state management, and API churn

  • Strong concern that shifting state (history, tools, RAG, workflows) into OpenAI increases lock-in and switching costs.
  • Several experienced users say they keep using basic chat completions + structured outputs and manage all state themselves; they see frameworks and SDKs as unnecessary abstraction and fragile black boxes.
  • Comparisons are made to AWS: high-level managed services vs commodity primitives; many predict LLMs will commoditize, making lock‑in strategies fragile.

Other design and usability points

  • Some developers praise built-in tracing and integrations (e.g., AgentOps) but complain the OpenAI dashboard still lacks features like full cost tracing and exports.
  • Questions about structured outputs: JSON escaping issues for LaTeX/code, preference for YAML/Markdown, and confirmation that Pydantic-style typed outputs still work.
  • Requests for TypeScript SDK and Realtime/audio support in Agents; both not ready yet.
  • Curiosity about using Computer Use for usability testing is met with skepticism: AI’s interaction patterns differ from humans.

Overall sentiment

  • Mixed but engaged: enthusiasm for simpler abstractions, integrated RAG and tools, and genuine developer experience improvements.
  • Counterbalanced by worries about price, lock‑in, rapid API churn, and whether agent frameworks truly solve real production problems versus simple, explicit LLM calls.