Summary

Drawing on Bell Labs’ 1940s systems engineering insight (optimize interactions, not components), this post argues that the current wave of agentic software development repeats historical mistakes by optimizing individual parts (filesystem for memory, bash as general tool) without considering the whole system. It proposes five engineering layers for production agentic software — Agent, Data, Security, Interface, and Infrastructure — and illustrates them with Dash, an open-source self-learning data agent.

以貝爾實驗室 1940 年代的系統工程洞察為起點,本文指出當前 agentic 軟體開發在重蹈歷史錯誤:用 filesystem 當記憶體、用 bash 當通用工具,這些是局部最佳化的症狀。提出五層架構(Agent、Data、Security、Interface、Infrastructure Engineering)並以開源 Dash 資料代理人實作說明。

Key Points

  • Five layers: Agent Engineering (orchestration, observability), Data Engineering (schemas, databases, pipelines), Security Engineering (RBAC, JWT, audit trails, per-request isolation), Interface Engineering (consistent auth across REST/Slack/MCP/CLI surfaces), Infrastructure Engineering (containers, streaming, scheduled tasks)
  • Read-only access is a tool configuration, not a prompt instruction
  • One user’s context bleeding into another is a data breach, not a bug
  • Agentic software = regular software with business logic replaced by agents; request/response → streaming across multiple surfaces
  • Dash open-source: team of agents (Leader, Analyst, Engineer) with six context layers, self-learning from error patterns

Insights

The security framing is unusually rigorous for an AI engineering post. Treating read-only database access as a PostgreSQL connection parameter (enforced by the database itself) rather than a model instruction is exactly the right approach — it eliminates an entire class of prompt injection attacks on data access boundaries. The “interface engineering” layer addresses a real gap: most agent systems treat all callers identically, but a Slack user ID, JWT token, and MCP client are different identity types that need different mapping to internal permissions.

Connections

Raw Excerpt

Read-only access IS NOT a prompt instruction, it’s a tool configuration. Actions should have approval tiers: reads run freely, writes need user approval, sensitive operations need admin sign-off. One user’s context bleeding into another’s is a data breach, not a bug.