Boundary Control Entity (BCE) was designed for humans: vertical slices named after the domain, one responsibility per layer, and the same structure in every project. The same properties save tokens and prevent wrong turns for coding agents.
Use case alignment. Ivar Jacobson introduced the pattern in 1992 to implement use cases: controls implement the use cases, boundaries connect them to the actors, entities hold the state. A business component groups the controls of closely related use cases, so each requirement lands in one or two named components, with high cohesion and low coupling built in. The agent compares the requirement with the component, sees what is missing, asks one targeted question and implements in one shot.
Context locality. The agent loads only the relevant business component, or one layer of it. Smaller context, fewer tokens, fewer stray edits.
Findability. The component name matches its responsibility, so the agent goes straight to the code instead of exploring the tree. Every skipped directory listing and file read is context the agent does not pay for.
Deterministic placement. New code has exactly one legal place: this component, this layer. The agent spends no tokens on deciding where a class belongs, and two agents produce the same layout. Without this rule, agents create util, service and helper packages within the first session.
Parametric knowledge. Thirty years of books, lectures and projects put BCE into the training data. The agent already knows what a boundary, a control and an entity are. Only project-specific conventions need documentation.
Canonical grounding. A package-info.java per business component is a short, authoritative summary. The agent reads it instead of crawling the package.
Technology-agnostic mapping. BCE is a stable, technology-independent interface for the agent. Boundary, control and entity mean the same whether the implementation is JAX-RS, a CLI or a web component. Technology-specific agent skills supply the implementation. A framework migration becomes a skill swap. The business architecture stays.
Predictable seams. Boundaries handle I/O, controls implement use cases, entities hold state. The agent generates tests per control, refactors one layer without touching the others, and a code review covers one component at a time.
Parallelism. One agent per business component, coordinated through narrow interfaces. The seams are explicit, so the agents work independently and the results merge with little pain.
Observability. A business component is a natural unit for tracing, logging and metrics. When agent-generated code misbehaves in production, the trace points to a component and a layer, not to an anonymous class somewhere in the tree.
BCE was built to reduce human cognitive load. For agents the effect is larger: humans tolerate a messy tree, an agent pays for every file it opens. See bce.design for the pattern and airails.dev for the agent skills.