A Smaller Core for Broader AI-Enabled Products

Separate durable business rules from generated workflows so product scope can grow without operational risk growing at the same rate.

One point from Theo Browne’s closing keynote at the AI Engineer World’s Fair stayed with me. He talked about terminals, editors, and other developer habits. I kept thinking about his point on project size.

Theo described software projects moving down one tier. Work that once needed a funded company can become a side project. A side project can become a weekend task. Some internal applications can shrink into a Markdown file that an agent runs on a schedule.

This sounds like a productivity claim: developers can build the same application faster. I think it changes product design too. When implementation gets cheaper, a team can support more customer outcomes without adding every variation to the permanent product code.

So the question changes. We still need to ask which features the team can finish this quarter. We also need to ask which parts the product must own, and which parts customers can build safely around it.

Figure 1. A conceptual version of the tier shift from Theo Browne’s keynote. This is a product-planning model, not measured productivity data.

The cost of breadth is changing

Software teams have always had to choose what they build.

A product manager can ask for regional approval flows, five export formats, a custom dashboard, a connection to a customer’s old enterprise resource planning (ERP) system, and a mobile interface for one warehouse device. Every request may be reasonable. The team still has one backlog and a limited number of engineers.

That limit shaped product strategy. Small companies usually went deep in one area because broad products were expensive. Supporting many use cases needed several teams, a large support organization, and years of code. A startup would pick one part of a larger platform and try to make that part much better.

Agents reduce the cost of a first working version. Current research shows the direction, although it cannot provide one reliable productivity number. METR’s task-completion time-horizon research measures the duration of software tasks that frontier agents, meaning current high-end models, can complete at a given success rate. That horizon has moved from short tasks toward work that takes human experts hours. Anthropic’s research on agent autonomy also found longer autonomous turns and fewer human interventions in its internal usage data. Product telemetry and controlled evaluations measure different things, so the numbers should not be mixed. Both show that agents can handle larger tasks.

This does not mean that an agent can run a software company. It means we can hand over a complete adapter, report, workflow, or small application and often get back something worth reviewing. That was much less reliable when AI coding meant generating one method at a time.

Larger delegated tasks let the team consider a broader product while agents handle more customer-specific details.

The product boundary moves

The product boundary separates the behavior that the vendor promises from the behavior that the customer assembles.

Traditional software-as-a-service (SaaS) products keep a lot of behavior on the vendor side. The vendor builds the workflow designer, every connector, the reporting UI, the notification templates, and a long list of configuration options. Customers wait for a roadmap slot or pay consultants to work around missing features.

An agent-capable product can own a smaller core and expose more of its capabilities through clear contracts. Customers can then build some workflows and integrations themselves. The product still owns shared state, permissions, business rules, and operations. The customer controls more of the customer-specific behavior.

I use three layers to think about this design.

Figure 2. Fast-changing, customer-specific features fit at the edge. Stable contracts protect the product core and make that edge replaceable.

The owned core contains the parts where one wrong decision can damage shared data, money, security, or trust. Identity, authorization, domain state, transactions, billing, audit records, and service-level objectives belong here. The product team defines their behavior and operates them.

The contract layer exposes safe operations on that core. It includes APIs, tool definitions, events, schemas, policies, quotas, preview operations, idempotency rules, and clear failure responses. This layer defines what outside code may do and how the product keeps control.

The generated edge contains customer-specific behavior: adapters, dashboards, exports, approval flows, notifications, and small interfaces. Professional developers will write some of it. Agents will generate some of it. Much of it can be replaced when the requirement changes.

This gives the product more breadth without putting every customer outcome into one permanent codebase.

Three labels for the backlog

Roadmaps need a simple way to separate these layers before every request becomes an “agent feature.” I would start with three labels.

• Invariant. What must remain true for every customer and every integration? Examples include authorization, ledger balance, data retention, and tenant isolation. The product team owns these rules.

• Capability. Which guarded operation should outside code be able to use repeatedly? Examples include creating a draft, pricing an order, requesting approval, and subscribing to an event. The product team owns the stable contract.

• Convenience. Which presentation, sequence, or adapter helps a specific user finish a task? Examples include a dashboard, export, notification, regional workflow, or legacy connector. The product team, a partner, the customer, or an agent can own this work.

An expense platform makes the difference clear.

The rule that an employee cannot approve their own expense is an invariant. The platform must enforce it for every caller.

“Submit this expense for approval” is a capability. The platform should expose it with a typed request, a documented state change, and a stable error when policy rejects the request. It also needs an idempotency key so a retry cannot submit the same expense twice.

“Send expenses over EUR 500 to the German country manager and summarize them in a Monday email” is a convenience. The customer can implement that workflow, and an agent can probably generate it from a short description. The platform still decides whether each approval is valid.

These labels keep core rules out of generated glue code. They also stop the product team from owning every customer-specific sequence forever.

The contract is product code

APIs have been product features for a long time. Agents make weak API contracts more expensive.

A human developer can read three documentation pages, inspect an example, notice that it is outdated, and adjust the code. An agent may recover too, but every unclear detail adds another chance to choose the wrong operation or argument. The result is more failed calls and more repair work.

Machine-readable descriptions help. OpenAPI lets humans and software discover HTTP operations and schemas. CloudEvents gives event producers and consumers a common format. The Model Context Protocol (MCP) exposes tools, resources, and prompts through standard operations that AI clients can discover. They solve different problems, but they all make capabilities explicit enough for software to inspect.

A protocol only describes the exchange. The operation still needs safe behavior.

Consider a refund operation. One refund_order tool that moves money immediately gives an agent too much room to cause damage after one wrong interpretation. A two-stage contract is easier to control:

plan_refund(order_id, amount, reason)
  -> proposal_id, calculated_effects, policy_findings, expires_at

commit_refund(proposal_id, approval_token)
  -> refund_id, final_state, audit_id

The first operation does not move money. It calculates the effects and returns policy findings. The platform may also store the proposal for later approval. The second operation changes the order and payment state and needs a separate approval. Both operations can be retried safely when the contract defines idempotency.

This design helps human-built integrations too. Agent use often exposes API problems that developers have tolerated for years: vague errors, hidden state changes, overloaded endpoints, and actions that cannot be previewed. Fixing those problems improves the platform for every client.

A serious extension contract should answer these questions:

• Can a caller discover the operation and understand when to use it?

• Are inputs and outputs structured and versioned?

• Does authorization match the business action, or does one broad token unlock everything?

• Can the caller preview the effects before changing state?

• Is retry behavior explicit and safe?

• Does a failure tell the caller to correct the request, retry, ask for approval, or stop?

• Can operators trace the action to a user, agent, contract version, and policy decision?

Teams often treat these as low-level implementation details while they rush to add visible features. In an extensible product, these details decide how many integrations and workflows the core can support safely.

Java still fits the core

Theo also challenged the habit of treating a programming language as part of a developer’s identity. That criticism is fair. Syntax is becoming easier to generate, and an agent has no preference for Java, Python, or TypeScript.

Java still fits the owned core and contract layer well. Java teams have spent decades building systems with typed boundaries, transactions, validation, compatibility, observability, and predictable runtime behavior. More outside code means more reliance on those properties.

A Java service can expose an OpenAPI description from typed endpoints, validate request models before business logic runs, publish standard events, and keep authorization close to domain operations. Frameworks such as Quarkus can also expose MCP tools, generate metadata at build time, and connect the same operations to tests and telemetry. A human does not need to type every line for these properties to matter.

Agents can recall framework syntax. Developers still need to define the behavior. Where does the transaction begin? Which state change is legal? What can a retry duplicate? Which data must stay inside one tenant? The answers decide whether the platform works.

Generated edge code should also be easy to replace. A stable Java core gives that code a predictable system to call. Customers can replace a workflow without migrating the system of record when the generated code changes libraries.

Breadth still has an operating cost

Cheaper implementation does not remove the cost of running a broad product. Every public contract creates a compatibility promise. Consumers may depend on every event. Every write operation increases the security boundary. Every generated integration can become a support request when it meets real production data.

The 2025 DORA report describes AI as an amplifier of an organization’s existing strengths and weaknesses. That fits platform breadth well. A team with clear ownership, fast tests, strong observability, and stable contracts can use agents to support more use cases. A team with unclear APIs and weak change control will produce more failures at a higher speed.

The generated edge therefore needs limits. Safety-critical decisions, shared data migrations, billing rules, and irreversible actions should stay close to the owned core. Generated code can propose a migration or prepare a transaction. The platform validates and runs it under explicit policy. A workflow cannot redefine an invariant because it arrived with a confident explanation and a green check mark.

Support boundaries need the same clarity. The platform team owns the contract and its documented behavior. Customers own generated logic beyond that contract unless they buy a managed extension. Anyone who has supported plugins knows this problem. AI increases the volume and speed, so the boundary must be easy to inspect.

Build a wider product with a small core

“Go bigger” can sound like a request for a larger backlog. A larger backlog gives the team more code to own. The better roadmap builds a small number of strong capabilities and makes them safe to combine.

For each planned feature, I would ask:

1. Which invariant does this feature depend on?

2. Which reusable operation is missing from the product?

3. Can we expose that operation with structured input, explicit policy, and observable results?

4. Which part is specific to one customer’s workflow or interface?

5. Can that customer-specific part be replaced without changing the core?

If most of the request belongs to the last two questions, a better contract, one reference implementation, and a test kit for customer extensions may be enough.

This also changes how a product team measures progress. Feature count tells us little about how easy the product is to extend. Better measures include the number of customer outcomes supported by a stable set of guarded capabilities and the time a customer needs to add a workflow without opening a ticket for the core team.

Broad platforms may own less code than we expect. They will own the parts that must stay stable and make the surrounding parts easy to create and replace.

My takeaway from Theo’s keynote is simple. Bigger ambition needs a clear boundary around the durable software. Keep that core small, protect it with clear contracts, and let the edge change as quickly as the tools allow.