LazAI Explainer Challenge
Claim Layer3 rewards
Over the past year, AI agents have become one of the most closely watched themes in tech and product circles. As models improve, tools become more usable, and workflows become more automated, more people are asking the same question: what form will AI ultimately take when it truly enters real-world work and everyday life?
Based on our recent work, we increasingly believe that software delivery will gradually evolve from traditional apps and websites into interfaces combined with AI agent collaboration, and in some cases into more agent-centric experiences. In the future, users may no longer interact only with static interfaces, but with AI agents that can understand context, help execute tasks, and support ongoing coordination.
If the previous generation of software was built around separate tools like Notion, Slack, calendars, and task managers, the next generation may not simply be another collection of interfaces. It may increasingly take the form of systems where AI agents help manage knowledge, coordinate work, and support execution.
That is one reason we started building Loom+. At its core, Loom+ is an AI-powered team collaboration platform. It brings together team knowledge bases, task management, meeting scheduling, smart search, and communication in one workspace, with AI agents helping connect knowledge, coordination, and execution. We are actively using it ourselves, refining it, and learning from its limitations. It is still early, but one thing is becoming clear: the next generation of software will not just help teams organize information — it will increasingly help them move work forward.
What we have learned, however, is that the gap between “AI looks smart” and “AI can reliably deliver outcomes” is not closed by a single prompt. It depends on product systems, engineering methods, and infrastructure for coordination.
A common assumption is that as long as models keep improving, AI agent products will naturally mature. In practice, we are finding that the picture is much more complicated.
Many of our recent experiments are still forms of ongoing development and productization on top of existing agent frameworks. What is changing is the way this development happens. Instead of relying only on programming languages, more of the process now involves using natural language to describe workflows, logic, and rules.
That shift is real, because today’s models do have meaningful natural language understanding and reasoning ability. But at the same time, we have become increasingly certain of one thing: at this stage, we should not overestimate or overtrust open-ended model reasoning in complex tasks.
Recent discussion around Harness Engineering offers a useful framework here. In simple terms, Harness Engineering is about designing the constraints, feedback loops, workflow controls, and improvement cycles around AI agents. The core issue it addresses is not whether a model can generate an output, but how to make agent outputs more reliable, consistent, and maintainable once strong generation capability already exists.
One of the clearest ways to describe this is: the model is the engine, but the harness is what makes the system usable. In the context of AI agents, the bottleneck is often no longer just model capability. It is whether the surrounding structure, tools, and rules are strong enough to support reliable execution.
In other words, the question is not just how much the model can understand, but whether the system has organized the right context, constraints, and workflow clearly enough.
One conclusion has become increasingly clear to us: the most effective approach today is not to give AI agents more room for open-ended improvisation, but to define the workflow, boundaries, and task structure clearly first — and then let the agent operate within a fixed scope.
A simple example: people often write instructions like “create a project folder,” and place naming rules, path requirements, and structural constraints later in the document. For humans, that is easy enough to follow. But for AI agents, this structure is often unstable. The agent may act on the first instruction while missing later constraints, or fill in details on its own, leading to outputs that drift away from the intended result.
If the instruction is rewritten directly as something like “create a project folder under this path using this naming format,” the result is usually much more stable. The point is not to remove all reasoning, but to reduce unnecessary ambiguity and turn a vague instruction into something closer to structured execution.
This points to a broader lesson: AI agent productization is still, at its core, about building clear, repeatable workflows and task rules. In the past, these rules were mostly enforced through code. Now, more of them are being expressed in natural language. But natural language does not replace engineering discipline. If the rules are not precise, complete, and locally clear, we still need structured design, modular workflows, and verifiable logic to make the system stable.
From an engineering perspective, many agent failures are not random at all. They tend to repeat in recognizable ways.
Recent work around Harness Engineering highlights several common failure modes. Agents often try to do everything in one shot, exhausting context halfway through a complex task. They may declare completion too early, treating partial progress as a finished result. Or they may mark work as done without enough validation, simply because the structure around them did not force proper checking.
This matters because it shows that the challenge is not just whether an agent can do something, but whether it can remain stable across long workflows, complex systems, and repeated interactions. A mature agent system is not one that succeeds occasionally. It is one that does not keep failing in the same ways.
Another misconception is that more context always helps. In reality, context has a practical limit. Once it becomes too long, too dense, or too cross-referenced, agents can lose track of structure, miss key constraints, and produce lower-quality outputs. More information does not automatically make the system better. Often, it makes it worse.
That is why, for complex workflows, we increasingly prefer an engineering approach: split things by responsibility, by level, and by reusable module. The goal is not to keep expanding prompts, but to design systems that agents can actually operate inside.
At the product level, we increasingly feel that truly usable agent products are not the ones with the most openness. For many ordinary users, too much freedom in the system actually makes it harder to use. Most people do not know how to talk to AI efficiently, how to write effective prompts, or even what kinds of tasks they should hand over to AI in the first place.
That is why the value of a more specialized agent is not that it limits AI for the sake of limitation. It is that it makes AI usable. A practical agent product usually needs to be built around a clear task, with familiar interactions and a low enough barrier that users can actually get value from it.
We already see this clearly in content workflows. Singularity Editorial Department is one of our attempts to productize content creation. It does not ask AI to operate in a completely open-ended space. Instead, it turns topic selection, structure, tone, information organization, and output standards into a more stable workflow. Under those conditions, the agent can produce high-quality content much more consistently, rather than behaving like a blind box each time.
In that sense, what users see may still look like “chatting with AI,” but from the system’s point of view, it has already become a more constrained and purpose-built workflow. At least today, we still cannot fully maximize both flexibility and stability at once. The most useful AI agents are often not the freest ones, but the ones most likely to help get the job done.
If we had to summarize one core engineering principle for the current stage of AI agent productization, it would be this: do not just fix this error once - make it an error the system does not keep repeating.
That is one of the most valuable ideas in Harness Engineering. When an agent makes a mistake, the right response is not just to patch the immediate problem. It is to turn that mistake into a new rule, checkpoint, feedback mechanism, or workflow improvement. That is how systems become more stable over time, instead of depending forever on human intervention.
This also makes the idea of a “white-box” system easier to understand. A white-box system is not just one whose outputs can be read, modified, and verified. It is one whose outputs and behavior can be caught, corrected, and improved systematically. The real standard for agent quality should not simply be whether it can succeed once, but whether people can reliably work with it and improve it over time.
These questions may sound like product and engineering questions, but they naturally connect to a broader conclusion: the next bottleneck for AI is not just intelligence itself, but coordination.
As AI agents move beyond chatting and content generation into execution, payments, coordination, and delivery, a new set of questions becomes unavoidable. How do agents identify themselves? Why should they be trusted? How do they coordinate with other agents? How do they handle payments and settlement? How do we verify execution? And how do repeated outcomes become reusable knowledge and experience?
That is why we increasingly believe the scarce layer is not just stronger models, but the infrastructure that allows agents to coordinate reliably and deliver outcomes over time. In that view, identity, reputation, payments, coordination, and result data are not isolated features. Together, they form the conditions that allow agents to move from isolated tools toward real participation in the Agent Economy.
And this is where Metis fits in. Metis is not just trying to position itself as AI infrastructure in a generic sense. The larger opportunity is to build infrastructure for the Agent Economy — infrastructure that helps agents identify themselves, establish trust, coordinate, transact, and deliver outcomes in a more programmable and verifiable way.
The distance between “can chat” and “can deliver” is not a single prompt. It is a full product system, an engineering approach, and a coordination layer that can support AI agents in real-world use. That may be one of the most important questions to keep thinking about as AI agent productization enters its next phase.
