Custom AI Agents Need the Mori Mindset
Custom AI agents should get smaller, not bigger. That is the real lesson from OKA's Mori, the home robot lamp reported by Wired: a device that reacts, comforts, and plays within a narrow role instead of pretending to be a universal assistant. If you build AI systems for actual teams, that design choice is not cute. It is disciplined.
I spend most of my time in workflows, not demos. The fastest AI projects I see in 2025 are not the ones with the longest feature list. They are the ones that own one trigger, one decision, and one handoff. Mori matters because it shows the same instinct in consumer form: constrain the job, make the behavior legible, and stop before the product turns into a mess.
Mori points to the real future of custom AI agents
According to Wired's source reporting, Mori is a nearly 12-inch lamp-robot from One Kind Artifact, led by Hua Wang, that follows people with its eyes, plays nature soundscapes, guides breathing, and deliberately does not try to be an Amazon Echo replacement. Wang's thesis is blunt: the product is about repairing relationships between people and their surroundings, not becoming a catch-all command layer.
That restraint is the part most business teams miss. In AI agent development, the instinct is usually to keep adding capabilities: answer support tickets, summarize meetings, update CRM fields, chase invoices, route approvals, maybe even manage a calendar. By sprint three, nobody can explain what the agent actually owns.
A lamp-robot is a better product lesson than a chatbot demo because the boundaries are visible. You know what Mori is for within seconds. You also know what it will not do. That second part is where trust starts.
Last month I worked on a support triage flow where the first brief asked for one assistant to classify tickets, search the help center, draft replies, escalate bugs, and create renewal-risk alerts in the CRM. We cut it down to one job: classify and route inbound requests with confidence thresholds and a human fallback. Misroutes dropped after the second tuning pass, adoption went up, and the team finally had a metric they could defend.
Why narrow AI beats feature-stuffed assistants
Users remember one reliable behavior. They do not remember 14 maybe-features.
That is why Mori feels coherent and so many AI conversational agents feel slippery. Mori sees you, reacts to you, and creates an ambient interaction. It is emotionally legible. Compare that with the usual overloaded assistant pattern: a voice layer bolted onto five systems, weak permissions, inconsistent retrieval, and just enough autonomy to create new failure modes.
Amazon Echo is a useful contrast class here. A general assistant can be convenient, and for commodity tasks that broadness makes sense. But broadness also creates expectation debt. The moment a system appears general, users assume it understands context it does not actually have.
In business, that gap gets expensive fast. An AI automation agent that can sometimes answer policy questions, sometimes trigger a workflow, and sometimes invent the wrong answer is worse than a narrower tool with a smaller surface area. Anthropic's guidance on building reliable agents makes this point in a more technical way: simpler compositions often beat agent sprawl. OpenAI's cookbook patterns land in a similar place when you look at the implementations that survive production.
The operator problem is not model IQ. It is scope creep.
Where custom AI agents earn their keep in business
The best business use cases for custom AI agents are boring on purpose. That is a compliment.
Think support triage, internal knowledge retrieval, quote preparation, onboarding checklists, order exception routing, or meeting follow-ups that push structured notes into the right system. Those are good targets because the boundaries are visible, the trigger is clear, and success can be measured.
In one e-commerce workflow, for example, a narrow agent only handled one event: orders with a shipment exception plus a customer email in the last 48 hours. It pulled order status, drafted a response from approved templates, and handed the case to a human if confidence or account value crossed a threshold. That is not glamorous. It is also the sort of AI workflow automation that teams keep because it saves real minutes every day.
The jobs a custom agent should own usually have four traits:
- a repeatable trigger
- a bounded data source
- an acceptable escalation path
- a measurable output
The jobs you should leave to software you already have are the ones with stable rules and no language ambiguity. If a normal integration or a deterministic automation can do it, use that first. AI integrations for business earn their keep in the messy middle: too variable for rules alone, too repetitive for humans to enjoy.
If you're mapping that messy middle, a focused implementation page like AI Personalized Learning with Integration is a useful example of how one agent-like system can stay tied to a narrow outcome instead of becoming a general assistant.
For a broader market read, McKinsey's latest State of AI research keeps showing the same pattern: value comes from targeted deployment inside workflows, not from scattered experimentation.
The case against turning every system into an AI assistant
Here is the strongest argument on the other side: general-purpose copilots reduce interface switching, give teams one place to ask for help, and can absorb new tasks over time. That is not wrong. In some environments, especially when users are expert operators and the underlying systems are well-governed, a broad assistant can be efficient.
I have seen this work in internal engineering environments where people know the data landscape, tolerate rough edges, and can spot bad answers instantly. A broad copilot sitting over docs, tickets, and repos can save time there.
But most teams are not operating under those conditions. In professional services and e-commerce, users need predictable behavior more than broad possibility. Every new integration adds one more auth path, one more permission question, one more place for stale context, and one more argument about ownership. The result is often slower adoption, not faster deployment.
Mori's lesson lands here again. Its charm comes partly from what it refuses to be. The same goes for custom AI agents in operations. If the system is bounded, people learn where it helps, where it stops, and when to override it. That is easier to govern, easier to test, and easier to keep alive after the pilot.
How to scope a custom AI agent without overbuilding it
When I scope an agent, I use a five-part filter before anyone discusses model choice.
First: one user. Name the exact operator. Support rep. Account manager. Sales coordinator. Not everyone.
Second: one trigger. New ticket. New form submission. Failed payment. Contract uploaded. If the trigger is vague, the build will drift.
Third: one data source of truth. Pick the system that matters most. If you need six systems on day one, you are usually masking a process problem.
Fourth: one success metric. Time saved per case, reduction in routing errors, faster first response, fewer manual touches. If success needs a paragraph, the scope is too wide.
Fifth: one escalation path. Decide what happens when the agent is unsure, blocked, or outside policy. NIST's AI Risk Management Framework is useful here even for non-regulated projects because it forces teams to think about failure handling, not just output quality.
This is also why AI agent development should begin with workflow design, not prompt design. Prompts matter, but they are downstream of role clarity. The best agent specs I read are closer to operating procedures than product wish lists.
The takeaway: build artifacts, not AI kitchensinks
The market does not need more pretend-general assistants. It needs more custom AI agents that do one job cleanly, expose their limits, and earn trust through repetition.
Mori is a consumer gadget, not an enterprise system. But its design instinct is exactly right for business: one role, one mood, one measurable outcome. Build like that and your next agent has a chance to survive contact with real users.
Start with the smallest useful artifact, not the biggest possible assistant.
Martin Kuvandzhiev
Co-Founder & CEO, encorp.ai
CEO and Founder of Encorp.io with expertise in AI and business transformation
LinkedIn