Port published an argument that context engineering and prompt engineering are complements rather than rivals, and the image they use to separate them is a good one: “the differences between context and prompt engineering are more akin to the differences between 2D and 3D.” A prompt is the flat instruction. Context is the depth behind it — history, memory, the relationships between entities, the systems an agent can reach before anyone tells it what to do. The practical claim that follows is the useful half: “context engineering automates what information AI agents can access, reducing the need to rewrite prompts.” Anyone who has watched a team iterate on wording for a week when the actual problem was that the agent could not see the deployment history will recognise the failure mode.
It is a conceptual piece and carries no numbers, which is worth saying plainly rather than dressing up. What it does carry is a name for the thing Port sells — a context lake, fed by the software catalog, exposed through an MCP server, and fenced with governance guardrails so a self-service action or a root-cause agent operates inside limits someone chose. They are careful not to oversell the substitution: “even with a solid context pipeline, well-designed prompts can enforce guardrails and direct agents to the correct result.” An internal developer portal arguing that its catalog is really an agent context layer is self-interested and also, structurally, correct — a service catalog is a typed graph of what exists and how it relates, which is exactly the shape a model cannot infer from a prompt.
The catalog’s Port record makes that argument concrete in a way the blog post does not, because a context lake has a schema and here it is: the Blueprints API defines the types, the Entities API holds the instances, the Scorecards API carries the judgments made about them, the Actions API and Action Runs API are what an agent is permitted to do and what it did, and the Audit API is the history that makes any of it reviewable afterward. Sixteen API pages, and those six are the noun list for the entire idea.
Port scores 31.3, thin on the Kin Score, with discoverability at 75.9 and operational transparency at 52.6 against contract quality at 0.0 and contract governance at 0.0. Agent Readiness is 19.8, agent-aware — spec_presence, agentic_access, auth_clarity and rate_limit_signal lit, everything else dark, including mcp_server despite the post naming MCP integration as part of the pipeline. Nothing in Port’s registered record points at one. That is the tension worth sitting with rather than the easy one: a company whose product is structured, queryable, machine-legible context about your software scores zero on the structured, machine-legible quality of its own contract. The argument is right. An agent still has to be told, by something other than a blog post, that Port is where the context lives.