Our View

Status: Living Document Last Updated: 2026-03-31

---

Overview

Our current view is that most teams should think about AI stacks as a practical systems-design problem, not as a race to assemble the most fashionable agent toolkit.

What matters is not whether a stack looks advanced from the outside. What matters is whether it helps a team build systems that are understandable, adaptable, safe, and commercially useful.

This page comes last on purpose. The earlier pages explain the landscape; this one explains where we currently land after looking across those options.

---

1. Start with the job, not the stack diagram

The first mistake teams make is starting with tools and architecture patterns before they are clear on the job the system needs to do.

Before choosing models, frameworks, memory layers, or orchestration runtimes, define:

• what the system is meant to achieve
• who it is for
• what level of reliability is required
• what data it needs access to
• what actions it must be allowed to take
• what level of autonomy is actually justified

In our view, the right stack is downstream of those answers.

---

2. Most teams should bias toward simpler systems

There is a lot of pressure to make systems look agentic, multi-agent, or autonomous before the basics are working. We think that is usually backwards.

For many real use cases, the best starting point is:

• a strong model
• well-structured context
• retrieval where needed
• a small set of well-defined tools
• clear safety boundaries
• observability from the start

That will outperform a more elaborate architecture that has weak context, poor data quality, and no operational discipline.

---

3. Context quality is often more important than stack novelty

A recurring pattern in the market is that teams over-focus on models and under-invest in context.

In practice, system quality often depends more on:

• how knowledge is structured
• how retrieval is done
• how fresh the data is
• how explicit the instructions and boundaries are
• how well the system keeps track of state and outcomes

That is one reason we care about context engineering. Better context can improve many different stack designs, while a weak context layer will usually undermine even the most advanced architecture.

---

4. Autonomy should be earned

We do not think autonomy should be the default posture.

Autonomous execution makes sense when:

• the task is genuinely open-ended
• the possible paths cannot be reasonably enumerated in advance
• the value of exploration outweighs the additional cost and risk

For everything else, we prefer structured flows with bounded decisions. They are easier to test, easier to explain, cheaper to run, and easier to govern.

---

5. Model choice matters, but architecture matters more over time

A strong model can dramatically improve early results. But over time, stack quality depends less on a single model choice and more on the surrounding architecture.

That includes:

• model routing
• memory boundaries
• execution controls
• auditability
• fallback behavior
• cost discipline

Teams that architect for swappability and clear interfaces are usually in a stronger long-term position than teams that build everything around one model vendor's current strengths.

---

6. We expect the "best" stack to remain context-dependent

We do not think there will be one universally correct AI stack.

Different contexts will keep producing different best-fit architectures:

• enterprise internal assistants
• coding agents
• customer-facing copilots
• research systems
• operations automation
• workflow-heavy back-office systems

The better question is not "what is the best AI stack?" but "what stack design is best suited to this system, this team, and this risk profile?"

---

7. Where our thinking is still evolving

We are still actively refining our view on:

• how far multi-agent specialization is genuinely useful outside a narrow set of tasks
• where long-term memory becomes operationally worth the complexity
• what the cleanest boundary is between workflow orchestration and agent reasoning
• when cloud execution is clearly superior to local execution
• how opinionated a stack should be before it becomes too rigid

This is not meant to be a universal doctrine. It is our current view, based on the patterns that seem most useful and durable right now.

---

8. How we currently view spec-driven development

We think spec-driven development is an important category in the current AI-native engineering landscape.

It matters because it gives the market a name for a real shift:

• more human effort moved upstream
• clearer requirements and design before implementation
• specs used as active context for coding agents
• stronger verification against intended behavior

That overlaps with our direction strongly.

But we do not currently treat spec-driven development as the full name for what we do.

Why not:

• our approach is broader than feature-delivery specs alone
• we care about domain discovery, bounded contexts, and wider systems-engineering structure
• we are building a reusable knowledge and context system, not only an implementation workflow

So our current view is:

• spec-driven development is a useful comparison category
• it overlaps meaningfully with our approach
• it is narrower than our full method
• it should inform our landscape understanding without replacing our own framing

---

9. How we currently view remote execution and background agent operations

We think remote execution and background agent operations are an important next-layer category in AI-native engineering.

It matters because it extends the space beyond:

• local IDE sessions
• foreground prompting
• human-triggered agent use only

And into:

• remote coding environments
• background or scheduled agents
• event-driven workflows
• unattended or semi-unattended execution
• stronger control-plane and observability questions

Our current view is:

• local-first is still the default starting point
• remote/background execution is a higher-maturity layer
• it becomes useful when the workflow is clear enough that unattended execution adds leverage rather than chaos
• approval boundaries, observability, and failure handling are first-class design concerns

We do not see remote/background agents as a replacement for good local workflow, specs, guardrails, or review.

We see them as an expansion layer for teams that already have stronger foundations and want to extend AI-assisted work into:

• PR-triggered review or validation
• scheduled checks
• background triage
• long-running analysis or repair attempts
• wider workflow orchestration

So our current stance is:

• remote/background execution is a meaningful landscape category
• it should be understood alongside spec-driven development, not instead of it
• it increases the importance of clear specs, environment design, approvals, and validation
• it is a genuine growth area in our own understanding and service readiness

---

Related

• What is an AI Stack? - definition and why the term matters
• Architecture - the major layers of the stack
• Trade-offs - the active design decisions and tensions
• Reference Stacks - how other people are structuring these systems