TechCrunch Sessions: AI points to a new stack: composable agents, tighter controls, fewer giant bets

TechCrunch Sessions: AI at UC Berkeley made one thing plain. The industry is moving away from the old pattern of calling one big model and hoping for the best. In its place is a messier, more practical stack: multi-agent systems, retrieval-heavy pipelines, and security layers built around the model because governance does not come built in.

None of this will surprise anyone who's spent the past year shipping AI systems. It still matters that this is now the message on stage, not just the reality platform teams deal with after the demo breaks.

Across talks from Anthropic, Google Cloud, Cohere, Toyota, UC Berkeley, and others, the same themes kept coming up. AGI talk is still around, but safety is getting tied to implementation details. "AI co-pilot" is giving way to agent orchestration. Enterprise buyers care less about raw model IQ than whether a system can operate inside policy boundaries without leaking sensitive data.

From one model to a stack

The biggest technical shift on display was architectural.

A year or two ago, plenty of teams treated LLM integration like API plumbing. Prompt in, response out, then some application code cleans it up. That still works for lightweight tasks. It breaks once you need consistency, permissions, retrieval, or multi-step action.

The replacement stack looks familiar by now:

• an intent parser to classify the request
• a retriever that pulls internal context from a vector store
• a planner that breaks work into steps
• a specialist model or tool that executes each step
• a policy layer that decides what can be seen, said, or done

The sample architecture discussed at the event lines up with what many teams already run: an orchestrator routes requests to an NLP component, a RAG retriever, and a task planner; the retriever hits a vector database like Pinecone or Weaviate; the executor hands off to a code model or domain-specific model with the right context window and tool access.

That's where most of the real product work sits now. Prompting matters. Model choice matters. But the hard part is system design: deciding what context to fetch, which agent gets authority to act, how to observe a chain of calls, and how to stop bad actions before they happen.

The "AI co-founder" pitch is loud, but the workflow is real

Tanka's Kisson Lin framed the next step as AI moving from co-pilot to co-founder. The label overshoots. The underlying workflow does not.

Teams want systems that can carry a workflow, not just generate text. That means an agent that can take a product idea, draft a spec, scaffold code, summarize competitor activity, maybe sketch a launch plan, then hand the work back to humans in a form they can actually use. Google Cloud's Iliana Quinonez pointed in the same direction with low-code agent builders that combine LLMs, RAG, and orchestration frameworks such as LangChain.

The appeal is obvious enough. The ROI argument gets stronger when the unit of work is a process instead of a single answer box.

A lot of "agent" products are still thin wrappers around brittle chains. They demo well because the task is narrow and the environment is controlled. In production, the harder questions arrive quickly:

• How often does the planner pick the wrong subtask?
• What happens when retrieval returns stale or conflicting documents?
• Can the agent explain why it took an action?
• Who approves side effects like sending messages, opening tickets, or changing code?

That is where a lot of agent hype meets engineering reality. Agent systems are useful. They also fail in ways a simple chat interface doesn't. Once software can act, traceability becomes mandatory.

Security has moved to the center

Cohere's Yann Stoneman focused on private deployments, encrypted inference, and policy-driven controls. That's the enterprise AI story now. Security is shaping the architecture from the start, not getting stapled on after a prototype works.

A few implementation details stood out.

One was token-level access control, enforced by a proxy or policy engine such as Open Policy Agent. That makes sense because enterprise AI failures often happen at the output layer. The model has broad context, then reveals data a user should not see. Traditional RBAC at the application layer doesn't fully solve that. You need output-aware filtering and policies tied to identity and context.

Another was on-prem or tightly controlled Kubernetes deployments, with multi-tenant isolation and service-mesh auditing. Not glamorous, but this is how AI gets bought in finance, healthcare, manufacturing, and government. Compliance teams do not care that your benchmark score improved by 3 points if they can't inspect network flows or prove where the data lived.

Homomorphic encryption came up too. It's worth being direct here: fully practical homomorphic inference at scale is still expensive and situational. It's a real area of research and product work, and there are cases where the overhead makes sense. Most teams today will get farther with standard isolation, strong key management, encrypted transport, careful data minimization, and aggressive policy controls. If a vendor talks about homomorphic encryption like a solved default, be skeptical.

Safety is getting more concrete, unevenly

Anthropic's Jared Kaplan talked about AGI timelines and the company's usual themes around interpretability and Constitutional AI. UC Berkeley's Ion Stoica pushed the other side: open-source audits matter, especially when frontier model development remains opaque.

That tension is healthy. The field still pulls in two directions.

One camp puts safety in model-level training techniques, alignment work, and internal evals. The other wants external inspection, reproducibility, and public scrutiny, especially when capability and control claims are hard to verify from the outside.

Both arguments hold up, to a point. Model alignment matters. So do plain system controls. A "safe" model can still produce an unsafe product if the retrieval layer is poisoned, tool permissions are sloppy, or logs are too thin to reconstruct what happened.

For working engineers, interpretability is still frustratingly immature. Plenty of vendors talk about visibility. Fewer can show anything useful beyond token traces, confidence proxies, or post-hoc rationales. In practice, safety in 2026 still looks like layered risk reduction: evals, filters, retrieval audits, approval gates, red-teaming, observability, and policy enforcement.

Less romance. More survival.

Toyota's example says more than another chatbot demo

Toyota's Kordel France described using NLX-style conversational interfaces with vector search and domain-tuned models to support repair workflows. That's one of the better enterprise examples because it maps cleanly to a high-friction task.

Field technicians do not need a philosophical assistant. They need the right repair procedure, the right parts context, and quick access to manuals without digging through bad internal tools.

A setup like this works because the scope is constrained:

• the document corpus is known
• the terminology is domain-specific
• the task is operational, not open-ended
• the cost of a wrong answer is high enough to justify guardrails

That's a good fit for RAG and domain tuning. Index manuals into a vector store, embed them with a sentence transformer, retrieve candidate passages, then wrap the output with task-specific logic and verification. The sample Pinecone workflow discussed in the source material is basic, but the pattern keeps showing up because it works.

It also exposes the next problem. Retrieval quality is a product feature. Bad chunking, weak metadata, stale documents, or naive similarity search can quietly wreck trust. Teams building these systems need people who understand embeddings, indexing strategy, relevance evaluation, and failure analysis, not just prompt templates.

What technical leads should take from this

A few things look increasingly settled.

First, orchestration is now a core competency. Whether you use LangChain, a homegrown workflow engine, Vertex AI Agents, or something else matters less than whether your team can build observable, testable pipelines. Ad hoc prompt chains won't hold up.

Second, RAG remains central, but it needs real discipline. Retrieval does not patch hallucinations by magic. It adds latency, complexity, and a new failure surface. Good RAG systems need document hygiene, ranking logic, evals, and feedback loops.

Third, policy has to sit close to inference. In regulated environments, assume you'll need output controls, audit trails, per-user visibility rules, and approval workflows for agent actions.

Fourth, low-code agent tooling will spread, especially through cloud platforms. That helps with prototyping and creates governance problems when teams treat it like spreadsheet automation. Getting an agent to run is easy. Knowing when it went off-script and who owns the blast radius is harder.

And finally, stop treating this as a model race inside your company. For many teams, the durable advantage will come from building a system that routes work well, protects data, exposes failures, and fits the organization it serves.

Less glamorous than AGI timelines. Much closer to where budgets get approved and production systems stop embarrassing people.