What the CrewAI Signal Conference Revealed About the State of Agents

Some people are calling 2025 “the year of agents,” but I think it’s more accurate to call it “the year of agent frameworks and agent runtimes”. Building an agent is easy, the hard part is deploying one.

Once your agent is in production, you’re suddenly dealing with everything you’d expect from production software—monitoring, tracing, evaluations and experiments, cost controls, versioning—plus a new category of unknowns specific to autonomous behaviour. Thankfully, the ecosystem is growing fast with platforms like CrewAI Enterprise, LangSmith (from LangChain), AWS Bedrock, and Google’s Vertex AI Agent Engine giving teams a solid foundation for running agents at scale.

Another big takeaway was watching how fast the agent ecosystem is creating entirely new product categories revolving around agent operations. The most noteworthy categories revolve around agent identity and agent action management: authentication, authorization, tool-call scoping, and full auditability of every action an agent performs. Because ultimately, if you’re planning to deploy agents for any purpose, this security and governance layer is not optional.

A theme that came up across nearly every talk: successful agents rely on hybrid architectures that combine deterministic code and LLM reasoning, executing side by side.

This approach is now fully supported in CrewAI’s framework through CrewAI Flows, which orchestrate deterministic functions (i.e. traditional code) and LLM-driven steps in a single workflow. It’s a simple principle: if a task can be solved deterministically (like transforming structured data, validating input, or formatting a payload), it should be. t’s consistent, fast, and cheap.

The LLM should handle the ambiguous parts: interpreting messy user intent, selecting the next action, synthesizing information, or generating a plan. This approach makes systems easier to debug, easier to observe, and far more resilient, because the non-deterministic component is isolated to the places where ambiguity is actually present.

Even as LLMs improve, this pattern won’t vanish. In fact, I believe it will increase, and even shift to the API side of the LLMs. When an LLM determines that code best solves the problem, it will write the code, execute it in a sandbox, and present the final results in its response to the user.

Another clear pattern from the conference: the leading teams aren’t treating agents as isolated features. They’re treating agents as full collaborators across the entire lifecycle of their domain, from the first conversation with a customer all the way through delivery, QA, and ongoing operations.

For consulting firms, this is a huge opportunity. Agents can sit in on early discovery calls, synthesize interviews, turn those into blueprints, expand those into PRDs and technical specifications, generate scaffolding for the implementation, produce tests, perform QA flows, and assist with UAT and documentation. In other words: everything that involves structured synthesis is now fair game.

Software teams should think about their internal SDLC the same way. Agents can assist with requirements gathering, architecture proposals, code generation, regression testing, and release notes. Software engineers have already been massively accelerated with coding agents like Cursor or Claude Code, the next natural steps are bringing in agents to assist with the fuzzy tasks that occur before and after code generation.

For SaaS companies, the opportunity exists on both sides of the fence:

1. Internal SDLC acceleration: The same lifecycle improvements consultants and engineering teams get.

2. Customer-facing agents: Most SaaS companies know their customers use only a fraction of their product. Agents can change that by acting as a 24/7 customer success engineer for every user with personalized, contextual support that understands the customer’s usage patterns, identifies pain points, helps configure features, and guides customers toward using more of the product they already pay for.

The takeaway across all of this is simple: Agents shouldn’t sit on the edges of your workflow. They should flow through the entire value chain.

One of the most enlightening takeaways for me didn’t come from a speaker, but from a conversation I had with an IBM consultant who made a compelling case for exploring Graph-powered RAG, where a knowledge graph is used instead of a vector database, alongside standard vector retrieval. His point wasn’t that vectors are wrong, it’s that graphs can represent structure and relationships in a way embeddings can’t. With a hybrid RAG (vector + graph) setup, you get the best of both worlds.

Before LLMs, building and maintaining a knowledge graph was slow, expensive, and required tons of manual work: reading documents, extracting entities, labeling relationships, designing an ontology, and continuously updating it. But with LLMs, we can hand off the labor-intensive tasks of extraction, clustering, and suggested relationships. Oversight is still essential, but the brute-force work has largely evaporated. Graph RAG used to be too costly for most teams. LLMs have changed that equation.

You don’t need to adopt a new approach tomorrow, but if your domain is complex, relational, or deeply structured, hybrid RAG is worth keeping on your radar.

Another conference theme: once agents start taking real actions, the entire security model changes. Traditional systems worry about users and services, but agents aren’t purely one or the other. They sit in a new category that doesn’t map neatly to existing models.

And this isn’t a future concern. Teams building production agents today have already hit these problems and had to solve them themselves or turn to the emerging vendors in this space. This new security paradigm means we need new answers to foundational questions:

Identity: Does the agent operate with the user’s identity? Its own identity? A delegated token? Which permissions does it inherit? Which should it not inherit?

Permissions: What permissions does the agent have? What can it not do? Agents should never have blanket access— they need scoped, revocable permissions.

Tool control: Which tools can the agent call? What inputs can it pass and under what circumstances? When is human approval required? Most of the risk in agents comes from actions, not text generation.

Auditing: As soon as agents can modify data or trigger workflows, you need a detailed log of what the agent did, when, why, which tool it called, with what parameters, and on whose behalf.

What’s fascinating is how quickly an ecosystem has formed around this. There are now entire companies specializing in agent authentication, delegated authorization, tool governance, and full action-level audit trails. These vendors exist because early adopters needed them, and every production team to follow will too. This is the new production layer.

Stepping back from the sessions, hallway conversations, and demos at Signal, the pattern was hard to miss: the biggest gains aren’t coming from bigger models, they’re coming from better systems. The real opportunity is in the application layer— hybrid architectures, improved context retrieval pipelines, agent-driven workflows, and proper identity and authorization frameworks.

And because most organizations haven’t deployed a single agent yet, this entire layer is still wide open. Teams who start building reliable, production-grade agent systems now will have a huge advantage not because they’re using a secret model, but because they’ve invested in the engineering patterns, operational guardrails, and domain workflows that let agents actually do real work.

This is the part that excites me. It’s early in the agent era, but the foundations are stable enough for anyone with a software background to start building meaningful, high-leverage agentic applications. The tooling is maturing. The frameworks are here. And the companies pulling ahead are the ones treating agents not as prototypes or side features, but as participants in their entire lifecycle of value creation.

The application layer is where teams will differentiate, and it’s where the next generation of software experiences will be built.