Why Organizations Struggle to Turn AI Into Real Business Value – Interview with Genna Barbara Zimmel
Genna Barbara Zimmel is a Technical Project Manager working across AI implementation, CRM architecture, and digital systems. Her work focuses on the layer between AI capability and real-world implementation: the data, workflows, memory, permissions, evaluation, and human decisions that determine whether an AI system actually works in practice. In this interview, she explores the Implementation Gap, what building Sibyl has taught her about context and conversational intelligence, and why governance becomes an architectural problem once AI systems can act.
Genna Barbara Zimmel, Founder of Torus Solutions
What problem are you most often brought in to solve when a company wants to use AI but its systems are not ready?
Usually, the company does not have an AI problem yet. It has a systems problem that AI is about to expose. The data sits in different places, the customer relationship management (CRM) system does not reflect how people actually work, ownership is unclear, and key decisions still depend on someone remembering what happened in a meeting three weeks ago. Then leadership asks where an agent can be added.
My job is often to slow that moment down just enough to map what the business is really trying to improve. I look at the workflow, the data moving through it, the people responsible for each decision, and where errors or delays are already occurring. Only then does it make sense to decide whether AI belongs in the process.
Otherwise, you are placing intelligence on top of confusion. It may produce a polished demo, but it will not produce a reliable operating system. The first problem I solve is readiness: making the underlying process clear enough that AI has something dependable to work with.
What separates an AI implementation problem from a technology problem?
A technology problem is usually specific: the API is failing, the integration is unstable, retrieval is returning the wrong information, or the model is not performing well enough on a defined task.
An implementation problem is broader. The technology may work perfectly, but people do not trust it, the workflow has not changed around it, nobody knows who owns the output, or success was never defined.
That is why buying a stronger model rarely fixes a weak rollout. AI implementation sits between technical delivery, operations, governance, and human behaviour. You have to decide where the system gets its context, what it is allowed to do, when a person must intervene, how mistakes are recorded, and whether the output is genuinely improving the work.
I think this distinction matters because organizations often keep tuning the technology when the real failure is adoption or operating design. The model is visible, so it gets blamed. The surrounding system is less visible, but that is usually where the implementation succeeds or fails.
What has building Sibyl taught you about memory and context that enterprise teams often overlook?
Building Sibyl, a conversational AI (sometimes described as an “annoyingly perceptive friend... in a good way”), taught me that memory is not simply a feature you switch on. It’s a product decision, a data decision and, in some cases, a safety decision. Sibyl is designed around persistent memory and structured context rather than treating conversation as a raw transcript log. A system that retains everything isn’t necessarily remembering; it may simply be accumulating.
Where this gets interesting is how structured context feeds Sibyl’s synthesis layer. One example is Reveal My Tree of Life, a feature on the web app that combines Hermetic Kabbalah and Human Design using birth data to generate a structured reading around dominant patterns, relationships, shadow and attraction. A user can then take that reading directly into a conversation with Sibyl, where it becomes additional context rather than a disconnected result.
Sibyl can also draw on other interpretive lenses, including astrology and Ayurveda, where relevant.
For me, it’s a small, self-contained example of context engineering: structured inputs, synthesis, contextual handoff and personalization aimed at producing one useful observation rather than simply accumulating more information.
Enterprise teams are solving the same problem in a different setting. More context isn’t automatically better context. A useful system needs relevant, permissioned and current information, with a clear reason for retaining it, and a plan for when it should stop being used.
As AI models become more accessible, where do you see the real competitive advantage moving?
I think judgment becomes more valuable, not less. As AI becomes capable of generating more analysis, content, recommendations and actions, organizations need people who can decide which of those outputs actually matter.
Someone still has to choose the right problem, define what “good” looks like, recognize when the system is confidently wrong, and decide when automation is creating value rather than simply creating activity. That requires business context as much as technical knowledge.
The strongest teams will not necessarily be the ones using AI everywhere. They will be the ones that know where AI should make a recommendation, where it can safely take an action, and where human judgment still matters.
I also think this changes what expertise looks like. Knowing how to produce an answer becomes less scarce. Knowing whether the answer is useful, what consequences follow from acting on it, and how it fits into a larger system becomes more important. AI can increase the amount of intelligence available to an organization. Judgment determines what the organization does with it.
When AI agents can act across CRM systems and workflows, which safeguards need to be built into the architecture itself?
Once an AI system can act, governance cannot live only in a policy document. It has to exist in the architecture.
I would start with least-privilege access: the agent should only see the data and use the tools required for its specific job. Read access should be separated from write access, and sensitive actions such as changing customer records, sending communications, issuing refunds or deleting data should require explicit approval.
Every action also needs an audit trail showing what the agent accessed, what it attempted and what happened. Inputs and tool calls must be validated because an agent can receive malicious or misleading instructions through documents, emails or external systems. There should also be limits on spending, frequency and the number of actions it can take before stopping.
Most importantly, organizations need a clear failure path. If confidence is low, permissions are missing or the situation falls outside the defined workflow, the agent should pause and escalate.
A safe agent knows not only how to act, but when it is not authorized to continue.
What should a company fix in its data or workflows before adding an AI agent?
Start with the workflow that exists, not the one described in the process document. Map where information enters, who changes it, which decisions are made, where work waits, and how exceptions are handled.
If three teams use different definitions for the same customer stage, an agent will not resolve that ambiguity; it will automate it. I have seen the same problem in customer relationship management (CRM) work, where the technology was functioning, but inconsistent processes and ownership meant the underlying data could not reliably represent what was actually happening with the customer.
The same applies to duplicated records, missing fields, inconsistent permissions, and undocumented workarounds. Before adding an agent, the company should establish a reliable source of truth, clear ownership, usable data standards, and an escalation route for cases that do not fit the normal path.
I would also reduce unnecessary steps before automating anything. There is little value in teaching an agent to move information through a process nobody would design today. Then define a narrow first use case with a measurable outcome: faster response time, fewer manual errors, better qualification, or improved completion rates.
Clean data matters, but operational clarity matters just as much. The agent needs to know what the business means, not merely where the fields are stored.
What are the clearest signs that an organization is falling into what you call the Implementation Gap?
The Implementation Gap is the distance between having access to artificial intelligence (AI) and being able to use it reliably inside real work.
The first sign is a collection of impressive pilots that never reach production. Another is high usage with no agreed measure of value: people are experimenting, but nobody can say whether time, quality, revenue, or risk has improved. You also see teams buying overlapping tools because there is no shared architecture, while employees quietly create their own workflows outside approved systems.
Responsibility becomes vague. IT owns the platform, the business owns the process, legal owns the policy, and nobody owns the outcome.
A further warning sign is that every failure is treated as a prompt problem. Prompts matter, but repeated errors often point to poor context, weak data, missing permissions, unclear escalation, or no evaluation process.
The gap becomes obvious when the organization can demonstrate what AI can do but cannot explain how it will be monitored, governed, adopted, and improved after launch. That is where experimentation has to become implementation.
How does “Support Over Dependency” change what you believe an AI system should and should not do?
Support Over Dependency means the system should help a person think, act, or communicate more clearly without becoming their authority, substitute, or emotional center.
With Sibyl, that shows up in how she handles difficult material. She doesn’t shut a conversation down because a topic feels sensitive, and she doesn’t perform shock or judgment either. If someone tells her they said something cruel to a friend out of jealousy, for example, she won’t simply validate or condemn it. She is designed to help get underneath it: what is that impulse protecting, and what might happen if they act on it? The principle is distillation over deflection, finding the real question underneath what someone brings her.
There is also a hard boundary. If language signals self-harm, suicidal ideation, or acute crisis, a separate safety layer intercepts before Sibyl’s normal personality logic runs and routes the person toward real-world crisis resources. For non-crisis isolation or loneliness, a softer layer can surface external peer-support resources.
The throughline is simple: Sibyl should leave someone more equipped for their actual life, not more attached to her. If someone feels understood but becomes less able to navigate their real relationships without the system, I would consider that a design failure.
If leaders could get one thing right before scaling AI across their organization, what would you want it to be?
Define the operating model before expanding the technology.
Leaders should be able to answer a few basic questions: What specific outcome are we improving? Which data and systems will the AI access? What can it recommend, what can it execute, and what still requires a person? Who owns its performance after launch? How will we evaluate quality, risk, and adoption over time?
If those answers are unclear, scaling simply spreads the uncertainty. I would rather see one narrow workflow implemented properly than ten disconnected pilots announced as transformation.
A strong first implementation creates the patterns the rest of the organization can reuse: permissions, evaluation criteria, logging, escalation, change management, and feedback from the people doing the work. It also gives leadership evidence rather than enthusiasm alone.
AI strategy should not begin with how many tools the company can deploy. It should begin with how the organization will make decisions about those tools once they become part of everyday operations. Scale is the result of a working system, not a substitute for one.
Read more from Genna Barbara Zimmel
