Systems

Problem space

The gap between what a product does and what a business charges for it. Revenue platforms fail when business rules that evolved through informal coordination get encoded as system assumptions. The job is modeling commercial logic as an explicit, evolvable set of domain boundaries.

Constraints

You're rebuilding a live system that enterprise customers depend on. Zero-downtime is table stakes. Correctness means something different to Engineering, Finance, and the customer, and the platform has to satisfy all three simultaneously. Migration is a product problem, not a technical one.

What makes it interesting

Pricing, activation, settlement, and value definition are coupled in legacy systems and must be separated into independently deployable domains. Each concern has different change velocity and different stakeholders. Decoupling them without breaking invariants is the design problem.

Problem space

Turning business logic that evolved through years of informal coordination into explicit, enforceable system boundaries. Most domain models fail not because they're technically wrong, but because they encode assumptions that made sense three business decisions ago.

Constraints

Domain boundaries must survive organizational change. The model has to be legible to engineers, product, and business stakeholders simultaneously. Implicit knowledge has to become explicit contracts without losing the nuance that made the implicit version work.

What makes it interesting

The hardest part is not building the model. It's getting agreement on what the model represents. Two teams looking at the same business process will draw different boundaries. The real work is reconciling their models of reality into something the system can enforce.

Problem space

Platform is an ownership model, not a team. The job is reducing coordination cost across teams with very different needs without becoming a dependency.

Constraints

DevEx must live where the work lives. Bringing external engineers to fix another team's environment is a rescue model that doesn't scale. Self-service is the only architecture that works.

What makes it interesting

The best platform work is invisible. But the worst platform work creates learned helplessness. The line between enablement and dependency is the entire design problem.

Problem space

AngelOS: 50+ autonomous agents across planning, operations, monitoring, and developer tooling. Dispatcher pattern routing user intent to specialized agents. From grocery planning that reads a shared calendar to trading bots with multi-broker interfaces to daily briefing synthesis.

Constraints

Agents that can't be audited can't be trusted. Agents that can't fail safely can't be deployed. Humans stay in the loop for decisions, not execution. Every agent must be observable and independently deployable.

What makes it interesting

The most interesting question is not 'can AI do this?' but 'should this agent have this level of autonomy?' Trust as an operating requirement applies to systems the same way it applies to people.

Problem space

Org design is the highest-leverage architecture decision. Team boundaries become system boundaries. The question is always: does this operating model produce autonomous performance at the next order of magnitude?

Constraints

Scaling from 8 to 40 engineers on a platform migration while maintaining velocity. Sequencing work across teams that don't share context. Managing departures that create knowledge concentration risk. Designing squad structures that don't fragment domain expertise.

What makes it interesting

The systems that break first in a scaling org are not the technical ones. They're the trust systems. Informal coordination that worked at 20 people becomes structural fragility at 200. The job is converting implicit trust into explicit contracts before it breaks.