Sentienta Blog

Category: Uncategorized

  • Managers Are Being Told to Implement AI

    Now They Have to Make It Work

    Business leaders are under pressure to move faster on AI. Competitors are adopting it, boards are asking about it, vendors are promising productivity gains, and employees are already using chatbots, copilots, and agents in their day-to-day work. At the executive level, the mandate can sound simple: implement AI.

    But that mandate becomes much more complicated when it reaches managers.

    For a manager, implementing AI is not just a tooling decision. It means figuring out how AI-assisted work should function inside a real team: how people and agents collaborate, how outputs are reviewed, how decisions are explained, how workflows change, and how accountability is maintained when the work is no longer produced by people alone.

    The research points to a clear pattern. AI adoption is moving faster than the management systems, intelligence infrastructure, and workflow designs needed to make that adoption useful at scale.

    Gartner reported that only 45% of managers say AI has improved their teams’ work as much as expected (Gartner, March 4, 2026). A subsequent study on agentic AI goes further: managers are no longer overseeing only people and tasks; they are increasingly accountable for the behavior, outputs, and risks of autonomous digital agents operating alongside their teams. Gartner also notes that AI-driven productivity gains can bring hidden oversight costs, with 75% of CHROs saying managers are more overwhelmed than ever (Gartner, May 6, 2026).

    IDC describes a related problem as an “intelligence gap”: organizations are piloting and deploying AI faster than they are building the intelligence infrastructure required to support good decisions at scale. In the same study, IDC found that only 39.6% of enterprises say AI governance is a top priority in 2026, even as agents take on broader decision-making roles across the organization. Without a reliable, traceable intelligence layer, governance becomes difficult to operationalize (IDC, June 24, 2026).

    BCG adds another dimension: their study found that 47% of respondents report spending more time managing and directing AI than doing the work itself, while 41% report increased cognitive load. BCG calls this the “joy paradox”: AI can make work better and harder at the same time. Their most important insight may be that the first wave of AI focused on individual productivity, but the next wave will need to transform collective work(BCG, June 3, 2026).

    Taken together, these findings sharpen the real problem.

    Companies are pushing AI into teams faster than they are redesigning the management, workflow, and intelligence systems around it. Managers are being asked to turn scattered AI activity into useful team performance, even though the operating model for doing that is still unclear.

    The AI Implementation Problem Now Lands on Managers

    For managers, AI-assisted work is becoming harder to see, harder to trust, and harder to coordinate.

    Managers are no longer reviewing work created only by people. They may be reviewing work shaped by prompts, copilots, agents, retrieved sources, automated workflows, and human edits. That changes the oversight question. It is no longer enough to ask whether the work was completed. Managers also need to understand what the AI contributed, what sources were used, what assumptions were made, what risks were surfaced, and what still requires human judgment.

    The same issue shows up in trust. A polished AI answer can look complete while resting on weak evidence, missing context, or untested assumptions. For managers, the question is not simply whether an output sounds right. It is whether the work behind the answer can be inspected before the organization acts on it.

    AI also creates a coordination challenge. It can help individuals draft, summarize, research, and analyze faster, but faster individual work does not automatically become better team performance. Without a shared place to review the work, preserve the reasoning, and connect it to a decision, AI activity can remain scattered across private chats, documents, and meetings.

    This is where the management burden becomes clear. Managers are expected to turn AI from a set of individual productivity experiments into a reliable way for teams to work. That requires more than access to models. It requires a practical layer for directing the work, reviewing the evidence, preserving the reasoning, and coordinating people and agents around shared outcomes.

    That is the missing layer.

    Managers do not need another AI tool that simply produces more output. They need a shared operating space where AI-assisted work can be directed, reviewed, challenged, captured, and turned into decisions the team can explain.

    How Sentienta Helps

    Sentienta is designed around that management problem.

    Sentienta gives teams shared Workrooms for AI-assisted work. Instead of scattering AI activity across private chats and disconnected tools, Workrooms give managers and teams a common place to collaborate with specialized agents, review contributions, compare perspectives, and keep the work connected to the decision being made.

    Within a Workroom, agents can take on defined roles. One agent might research, another might challenge assumptions, another might draft, and another might evaluate risks. The point is not just to generate more answers. It is to make the work process visible: who contributed what, what evidence was used, what tradeoffs emerged, and where human judgment is still needed.

    Sentienta also helps preserve the reasoning that matters. Key Ideas capture important claims, assumptions, risks, decisions, and open questions so they do not disappear into a long chat history. That gives managers a way to carry forward the working knowledge created during AI-assisted collaboration, rather than asking teams to reconstruct it later from scattered transcripts.

    This matters because the next phase of enterprise AI will not be measured only by how quickly individuals can produce drafts, summaries, or analyses. It will be measured by whether teams can use AI to make better decisions, coordinate more effectively, and preserve the context needed to act with confidence.

    Executives are asking organizations to move faster with AI. Managers are being asked to make that speed useful.

    To do that, they need practical systems for directing AI-assisted work, reviewing what matters, preserving decision rationale, coordinating people and agents, and turning saved time into better collective judgment.

    That is what Sentienta is built to support.

  • Chat History Is Not Organizational Memory

    Enterprise AI is moving from individual productivity into shared work. Teams are no longer using assistants only to summarize documents, draft emails, or answer isolated questions. They are bringing agents into product planning, customer research, governance reviews, technical investigations, operational workflows, and strategic decision-making.

    That shift creates a new version of an old organizational problem: important knowledge disappears.

    A team may have a valuable AI-assisted discussion in which one agent surfaces a risk, another proposes an implementation path, a human reviewer challenges the assumptions, and the group reaches a decision. In the moment, the work feels productive. But a week later, the durable value is hard to find. What did we decide? Why did we reject the other option? Which risks were still unresolved? What customer insight changed the direction?

    Too often, the answer is: somewhere in the chat history.

    The problem is organizational amnesia

    Organizations have always struggled to remember what they learn. Knowledge gets lost through turnover, silos, undocumented decisions, shifting priorities, and tools that capture activity without preserving meaning. AI does not automatically solve that problem. In some cases, it can make it worse by helping teams generate more analysis, more discussion, and more decisions without creating a reliable way to carry forward the knowledge that matters.

    Recent enterprise AI writing is starting to name this risk more clearly. Harvard Business Review recently warned that generative AI can contribute to decay in the accuracy and quality of organizational knowledge when companies fail to manage the knowledge layer around AI-enabled work (Don’t Let AI Slop Muck Up Your Company’s Processes). CIO has also described “organizational amnesia” as a risk in the age of AI, especially when institutional knowledge is not captured in a form that future teams and systems can use (Preventing organizational amnesia in the age of AI).

    This is not just a documentation problem. It is a continuity problem. Enterprise work depends on decisions, assumptions, objections, tradeoffs, lessons, and unresolved questions that accumulate over time. If those disappear into transcripts, teams are forced to rediscover what they already knew. Decisions get repeated without their original context. Risks raised in one discussion fail to inform the next. Useful patterns remain local instead of becoming shared organizational knowledge.

    As agents become part of real workflows, the question is not only whether AI can help people do more work. The question is whether AI can help the organization remember what the work taught it.

    A transcript is not memory

    A transcript records what was said. Organizational memory preserves what matters.

    That distinction is becoming central to enterprise AI. In a shared AI Workroom, the lasting value is rarely the entire conversation. It is the smaller set of decisions, ideas, risks, assumptions, patterns, and open questions that should survive beyond the session.

    Imagine a product team using a Workroom to evaluate a new customer-facing automation. One agent reviews customer needs, another checks policy and governance concerns, and another drafts implementation options. The discussion may be long, but the reusable knowledge is more specific: the launch criteria the team agreed on, the assumption they rejected, the customer objection that changed the positioning, the risk that needs legal review, and the implementation pattern that may apply to future launches.

    If all of that remains buried in a chat log, the organization has technically captured the conversation but practically lost the learning.

    This is why enterprise AI needs a layer between raw conversation history and formal documentation. Raw transcripts are too noisy. Formal documentation often arrives too late, if it arrives at all. The missing layer is working knowledge: the important ideas that emerge while people and agents collaborate, before they become policy, process, roadmap, or strategy.

    Where Key Ideas fit

    This is the role of Key Ideas in Sentienta.

    Key Ideas are a way to preserve the important concepts that emerge from human-agent collaboration so teams can revisit, refine, challenge, and reuse them.

    A Key Idea might capture a decision the team made, a strategic principle that should guide future work, a recurring customer concern, a risk pattern that needs review, a product assumption that remains unvalidated, or an unresolved question that should carry into the next session. The value is not that the idea is final. The value is that it does not disappear.

    In Sentienta v2, Workrooms create the shared context, governance controls agent action, and Key Ideas preserve the learning that emerges from that collaboration.

    Key Ideas extract and encode the important claims emerging from a workroom conversation, not just a flat summary of what was said. It links those ideas into a structured tree, so supporting, competing, refined, or unresolved ideas can be understood in relation to each other. It also identifies ideas that need user input to resolve ambiguity, make a decision, or move the discussion forward. The most important ideas are surfaced both in the strip at the top of the workroom and in the Session Assist panel for easy review.

    That matters because activity records and organizational memory answer different questions. An activity record can show what happened: an agent drafted a GitHub issue, posted to Slack after approval, or completed a brokered service action. But the deeper learning often lives one level higher. Why was the action taken? What tradeoff did the team accept? Which assumption shaped the decision? What risk should inform the next project?

    Governance helps an organization know what agents did. Key Ideas help preserve why the work mattered.

    Making AI work cumulative

    The first wave of AI adoption focused on speed: faster writing, faster research, faster coding, faster summarization. The next wave is about coordinated work. Teams will increasingly collaborate with multiple agents across shared contexts, and those agents will participate in planning, analysis, operations, customer workflows, engineering processes, and governance reviews.

    Other enterprise AI commentators are pointing in the same direction. TechTarget recently described AI collaboration tools as creating a new category of enterprise assets: institutional memory that is captured, organized, and reused by machines, while also raising governance and access-control questions (CIOs must rethink governance for AI collaboration tools). TechRadar has made a related point from the scaling side: AI programs struggle when knowledge remains scattered, and more durable context is needed for agents to inherit institutional knowledge rather than improvise each time (Why most AI programs stall, and what it will take to scale them).

    Sentienta v2 is designed around the belief that enterprise AI needs more than isolated assistants. It needs shared spaces for collaboration, governed access to external services, approval paths for meaningful actions, activity records for accountability, and a way to preserve the ideas that should outlive the conversation.

    The future of enterprise AI is not just agents that can answer questions or complete tasks. It is organizations that can remember, refine, and reuse what their people and agents discover together.

  • Enterprise AI Needs a Governance Layer

    Employees are no longer just chatting with AI models. They are beginning to work with agents that can act: connecting to services, operating browsers, reading documents, searching repositories, calling APIs, and using MCP* tools tied to external systems. Some can draft, retrieve, send, modify, or create information across the same systems where real company work happens.

    A chatbot answers a question. An agent participates in work. That is a meaningful shift, and it creates a governance problem that most organizations are only beginning to confront.

    The Access Problem

    Every employee needs powerful AI agents to do their work, but their needs differ.

    An engineer needs Slack and GitHub access through their agent. They don’t need access to the file server hosting IP documents and contracts. Legal needs that file server, but not GitHub. HR needs employee records on a company server, but not customer contracts. A DevOps lead may need write access to production infrastructure but a product manager does not.

    The access each person requires depends on their role, and the agents acting on their behalf should inherit exactly those boundaries and nothing more. Today, many companies face the opposite: a free-for-all of ungoverned agents operating with whatever access their users happen to have, or can reach through unmanaged local tools. No visibility. No boundaries. No institutional record of what happened.

    This is not a speculative concern. A January 2026 CIO report found that roughly half of employees are already using unsanctioned AI tools at work—with enterprise leaders themselves among the major culprits. And banning these tools does not solve the problem: a June 2026 study reported by TechRadar found that two in three office professionals used AI tools despite explicit policy restrictions. Prohibition drives usage underground; it does not eliminate the risk.

    Agents make company resources useful and employees more productive. But without a control plane, the organization has no reliable way to ensure that agent capabilities match role-appropriate access.

    Where Workrooms Change the Picture

    Last week we introduced Workrooms: shared spaces where cross-functional teams collaborate with AI agents around a problem, project, or decision. Workrooms are where the governance challenge becomes most visible.

    When Legal and Marketing both participate in the same Workroom, the agent Legal brings should carry different controls than the agent Marketing brings. Legal’s agent can reach contracts; Marketing’s cannot. Engineering’s agent can access the code repository; Legal’s cannot. The Workroom inherits each participant’s scoped permissions, so collaboration does not blow open access boundaries.

    This is where role-level governance meets team-level collaboration. A shared workspace must let people work together without silently granting every participant’s agent access to every other participant’s resources. The control plane has to follow the work into the room.

    How Sentienta Addresses This

    Sentienta provides the governance layer that lets teams bring powerful agents into shared workspaces while keeping access, actions, and accountability under enterprise control.

    Enterprise Admin is the control plane, giving organizations a centralized surface for managing enterprise membership, trusted domains, roles, and service access. This is not just a per-user settings page. It is the organizational layer where admins decide which AI capabilities and connected services are available to different roles.

    Admin-governed service access: Sentienta lets administrators decide which connected services are available to enterprise agents and who can configure them. Instead of every user running their own uncontrolled desktop agent, an organization can provide approved agents with approved capabilities: for example, one agent may be configured for GitHub and Slack, another for document-oriented local file access, and another for governed desktop automation. These controls are applied through enterprise roles, admin settings, and agent-level service configuration.

    Workroom-aware enterprise boundaries: Workrooms are shared spaces, so governance has to account for who is in the room. Enterprise-connected agents and services are governed by the Workroom context. If outside participants join a Workroom, enterprise agents are turned off by default unless explicitly approved. This prevents accidental exposure of enterprise capabilities to external collaborators.

    Agent execution targets and the Enterprise Bridge: Agents can be configured for different execution paths, including cloud models, desktop automation, and enterprise-hosted bridge services. The Enterprise Bridge is especially important for enterprise agents that run against company-managed infrastructure rather than an employee’s unmanaged device. It gives admins a controlled way to expose approved services, such as OpenClaw, MCP-based tools, or Local File Services, to approved agents. It also gives the organization a clearer audit trail for what agents attempted to do and which bridge handled the work. Instead of relying only on unmanaged local automation, the organization can provide powerful agents through infrastructure it owns and governs.

    Human approval for consequential actions: Reading, reasoning, summarizing, and drafting should remain fluid. But when an agent is about to send, publish, modify, merge, or otherwise change external state, Sentienta can require human approval before the action executes. This gives organizations a review point where it matters without adding friction to every interaction.

    MCP as a governed service surface: MCP-based tools can be powerful because they let agents reach external systems. In Sentienta, MCP services can be exposed as part of the governed service layer, where admins decide which services are available and which roles may use them.

    Activity records and auditability: Sentienta records agent activity, service use, approvals, and Workroom context so organizations have a record of how agents were used. This does not magically solve every security or compliance problem, but it gives enterprises visibility they do not get from unmanaged agents running independently across laptops and personal toolchains.

    Governance Enables Capability

    AI governance is not the opposite of powerful AI. Governance is what lets companies adopt powerful AI responsibly.

    Without a control layer, the rational organizational response is caution: restrict what agents can do, limit who can use them, or look away and hope nothing goes wrong. With a control layer, the organization can say yes: yes to service-connected agents, yes to desktop automation through approved infrastructure, yes to GitHub and Slack integrations, yes to MCP tools, yes to shared Workrooms where people and agents work together. But yes with appropriate permissions, layered scoping, approval where it matters, and a record of what happened.

    That is the governed path. Sentienta gives organizations the confidence to let teams use more capable agents in the places where real work happens.

    * MCP support is currently available through a limited beta. Availability, supported providers, tools, and setup procedures vary by account. Contact Sentienta for access.

  • When People and AI Agents Work Together

    Sentienta Workrooms give people and their agents a shared, evolving context

    Last week, we introduced Workrooms as Sentienta’s answer to the AI Silo Effect: the problem of AI-assisted work getting trapped in private chats.

    This week, let’s make that concrete.

    A Workroom is a shared space where multiple people collaborate with AI in the same running context. The host creates the room and invites participants. Participants contribute to the shared conversation, bring in agents that represent their expertise, and return to the room as the work develops over time.

    The result is not one generic assistant serving the whole team.

    It is a room where people and their agents work together.

    Multiple participants, one shared context

    Most AI tools are built around one user and one private thread. That works well for individual tasks, but teams need a shared place where AI-assisted work can happen together.

    In a Workroom, the host invites participants into a shared conversation. Once they join, everyone is working from the same context. The discussion, the decisions, the tradeoffs, the objections, and the outputs all live in the room as the work develops.

    That changes the way a team collaborates with AI. Instead of one person asking an assistant a question, getting an answer, and then reporting back, the work can happen where the group can see it and build on it. The shared context becomes the place where the team’s understanding accumulates.

    A Workroom does not require every person to be present for every moment. But it does give the team one place to return to, one context to build from, and one shared record of how the work is moving forward.

    Each participant brings their own agentic perspective

    A Workroom is not just a shared chat with one AI assistant attached.

    Each participant can bring agents into the room that represent their own expertise, responsibilities, tools, and point of view. A product lead might bring an agent that understands the roadmap and customer priorities. An engineer might bring an agent that can reason about implementation constraints. A designer might bring an agent that critiques flows and interaction patterns. A legal lead might bring an agent that knows the company’s IP posture, preferred contract positions, and risk tolerance.

    That is a very different model from asking the whole team to rely on one general-purpose assistant.

    Teams are valuable because people notice different things. They carry different context. They worry about different risks. They define success through different lenses. Workrooms preserve that diversity instead of flattening it into a single AI voice.

    The room can include multiple agentic perspectives, each connected to the participant who brought it, all working from the same shared context. The agents can participate while the work is still being shaped.

    And because participants control their own agents, the room can evolve with the work. A participant can bring in a new agent when the conversation enters a new domain. They can turn off an agent when they do not want it participating. This lets the right expertise enter the shared context at the right time. The Workroom remains flexible because the team’s needs are flexible.

    Private thinking still has a place

    Shared collaboration does not mean every thought belongs in the shared thread.

    People use AI privately for good reasons. They ask rough questions. They test weak ideas. They clarify their own thinking before speaking. They rehearse an argument. They explore whether a concern is real before raising it with the group.

    A useful shared AI workspace should not take that away.

    Workrooms support Private Aside, so a participant can consult their own agents without adding that exchange to the shared Workroom dialog. That gives people a place to think before they contribute.

    This matters because the goal of a Workroom is not radical transparency. The goal is better shared work.

    The team does not need to see every half-formed question or discarded idea. It needs the contributions that should shape the work: the objection worth raising, the insight worth sharing, the decision worth recording, the artifact worth preserving.

    Workrooms run asynchronously

    Teams do not always work at the same time.

    Someone is in meetings. Someone is in another time zone. Someone has twenty minutes between calls. Someone else is deep in focused work and will not return until tomorrow.

    A Workroom is designed for that reality. It does not depend on everyone being present at once. Participants can drop in when they have time, review what has happened, contribute to the shared conversation, and leave the room to keep moving.

    Agents make that asynchronous model more powerful. A participant’s agents can continue to represent that participant’s perspective while they are away. They can respond to questions, raise concerns, contribute expertise, or keep a particular lens active in the room even when the person is not currently present.

    That promise only works if the participant can trust the system.

    If an agent contributes while you are away, you need to know what it said, where it intervened, and what effect it had on the conversation. Otherwise, “agent as proxy” starts to feel less like leverage and more like something you have to babysit.

    The Workroom model is designed around that return experience. When a participant comes back, they are not expected to read every line from scratch or wonder what happened in their absence. They can see what their agents contributed, review the state of the work, correct course if needed, and decide where to re-enter the conversation.

    That is what makes asynchronous collaboration feel controlled rather than chaotic. Your agents can keep your perspective active while you are away, but you still have an accountability trace when you return.

    A meeting requires everyone to gather at the same time. A chat thread often moves forward without the right context. A private AI conversation helps one person, but does not automatically help the group.

    A Workroom gives the team a shared environment where people and agents can keep contributing around the same work.

    Conversation becomes work

    A Workroom is not only a place to talk with AI. It is a place where the conversation can turn into durable work.

    That distinction matters because teams do not collaborate in order to produce more messages. They collaborate to make progress. They need decisions, plans, drafts, tasks, artifacts, and a clear sense of what matters next.

    Workrooms are designed to keep the conversation and the work connected.

    Activity can capture important decisions, interpretations, questions, and outcomes. Tasks can show delegated work and operational progress. Artifacts can preserve the outputs the group wants to keep, refine, store, or delete.

    This helps prevent a familiar problem: the important discussion happens in one place, the task gets created somewhere else, the output lives in another tool, and the reasoning behind it slowly disappears.

    In a Workroom, the discussion and the durable outputs remain part of the same working context.

    That is especially important when AI is involved. AI can generate a lot of material very quickly. Some of it is useful. Some of it is temporary scaffolding. Some of it should become a decision, a draft, a task, or an artifact. Some of it should simply disappear into the background.

    A Workroom gives the team a way to separate the durable from the disposable.

    Long-running work needs more than a transcript

    The real value of a Workroom becomes clearer as the work stretches over time.

    A short conversation can survive as a thread. A long-running project cannot. Once a Workroom spans hours, days, or weeks, the team needs more than a record of everything that was said. It needs durable takeaways: the decisions that still matter, the assumptions the group is carrying forward, the open questions, the artifacts produced, and the claims the team has come to believe.

    This is the difference between shared history and shared state.

    Shared history is the transcript: what happened, in what order, and who said what. Shared state is what the team currently understands. It includes the decisions that are still active, the paths that have been ruled out, the unresolved tensions, the assumptions that remain in force, and the next questions that need attention.

    That distinction is what makes a Workroom more useful than asking a generic AI system to summarize a long thread. A summary compresses history. A Workroom needs to maintain state. It has to preserve the shape of the work as it changes, not just produce a shorter version of what was said.

    That is especially important in an asynchronous environment. A participant may step away while their agents continue to represent their perspective. Someone else may join later. The host may return after a day of other work. In each case, the question is not, “Can I read the entire transcript?” The question is, “Can I quickly understand where the work stands?”

    This is why Workrooms need artifacts and takeaways, not just conversation history.

    Tasks help the team see what needs to happen. Artifacts preserve the outputs worth keeping. And Key Ideas, which we will cover in a future post, are central to making long-running Workrooms usable: they track the essential claims and learnings that emerge across many interactions, so the team does not have to manually summarize the room every time someone comes back.

    That is the larger promise of Workrooms. They are not just a better place to talk with AI. They are a shared environment where the team’s decisions, context, artifacts, and next steps remain available to the people and agents who need them.

  • The Control Collapse: How Open Models and Distributed Hosts Are Rewriting AI Risk

    In late 2025, we explored a provocative shift in AI development: full-stack openness, exemplified by Olmo 3, which grants users control over every stage of a model’s lifecycle, from training data to reward shaping. That evolution, we argued, dismantled traditional visibility boundaries and redistributed both creative power and liability. What we didn’t anticipate, at least not fully, was how fast the deployment landscape would unravel alongside it.

    New research from SentinelLabs reveals a second, equally disruptive force: the rapid decentralization of AI infrastructure via tools like Ollama. With little more than a configuration tweak, developer laptops and home servers have become persistent, public-facing AI endpoints that are fully tool-enabled, lightly secured, and difficult to trace centrally at scale.

    Together, these forces represent a fundamental shift: AI risk is no longer a function of model capability alone, it’s a question of where control lives and what surfaces remain governable. In this post, we chart how openness at both the model and infrastructure layer is collapsing traditional chokepoints, and what this means for security, compliance, and enterprise trust.

    A Risk Surface with No Chokepoints

    The evolving AI risk landscape isn’t defined by any one model or deployment choice, increasingly it’s defined by the disappearance of meaningful control boundaries across both. On one end, Olmo 3 marks a shift in model lifecycle transparency. Now individual developers and small teams don’t just have access to powerful models, they have a full recipe to build, customize, and reshape how those models learn, reason, and prioritize knowledge from the ground up. Complete ownership over data, training scripts, optimization paths, and reinforcement dynamics gives rise to deeply customized systems with few inherited safeguards and without centralized governance enforcement.

    On the infrastructure side, Ollama embodies simplicity: an open-source tool built to make running local LLMs effortless. But that ease of use cuts both ways. With one configuration change, a tool meant for small-scale development becomes a publicly exposed AI server. The SentinelLabs research found over 175,000 Ollama hosts reachable via the open internet, many from residential IPs. Critically, 48% of them support tool-calling APIs, meaning they can initiate actions, not just generate responses. This shifts their threat profile dramatically from passive risk to active execution surface, potentially transforming a lightweight dev utility, when misconfigured, into a sprawling and largely unmonitored edge network.

    Together, Olmo and Ollama illustrate a compounding risk dynamic: decentralized authorship meets decentralized execution. The former enables highly customized behavior with few inherited safeguards; the latter allows deployments that bypass traditional infrastructure checkpoints. Instead of a model governed by SaaS policies and API filtering, we now face a model built from scratch, hosted from a desktop, and callable by anyone on the internet.

    Based on these findings, this may represent an emerging baseline for decentralized deployment: the erosion of infrastructure chokepoints and the rise of AI systems that are both powerful and structurally ungoverned.

    Unbounded Risk: The Governance Gap

    The SentinelLabs report highlights what may be a structural gap in governance for locally deployed AI infrastructure. The risk isn’t that Ollama hosts are currently facilitating illegal uses, it’s that, in aggregate, they may form a substrate adversaries could exploit for untraceable compute. Unlike many proprietary LLM platforms, which enforce rate limits, conduct abuse monitoring, and maintain enforcement teams, Ollama deployments generally do not have these checks. This emerging pattern could unintentionally provide adversaries with access to distributed, low-cost compute resources.

    Where this becomes critical is in agency. Nearly half of public Ollama nodes support tool-calling, enabling models not only to generate content but to take actions: send requests, interact with APIs, trigger workflows. Combined with weak or missing access control, even basic prompt injection becomes high-severity: a well-crafted input can exploit Retrieval-Augmented Generation (RAG) setups, surfacing sensitive internal data through benign prompts like “list the project files” or “summarize the documentation.”

    What emerges is a decentralized compute layer vulnerable to misuse. Governance models built around centralized actors apply strict bounds:

    • Persistent accountability surfaces: audit logging, model instance IDs, traceable inference sessions.
    • Secured APIs by default: authenticated tool use, rate-limiting, and sandboxed interactions as first principles.
    • Shared oversight capacity: registries, configuration standards, and detection infrastructure spanning model hosts and dev platforms alike.

    Absent these guardrails, the open ecosystem may accelerate unattributed, distributed risks.

    What Needs to Change: Hard Questions in a Post-Control Ecosystem

    If anyone can build a model to bypass safeguards—and anyone can deploy it to hundreds of devices overnight—what exactly does governance mean?

    Two realities define the governance impasse we now face:

    1. Intentional risk creation is accessible by design.
    Open model development workflows give developers broad control over datasets, tuning objectives, and safety behavior, with no checkpoint for legality or malice. How do we govern actors that intend to remove rails, not accidentally stumble past them? What duty, if any do upstream hosts, model hubs, or toolmakers bear for enabling those pipelines?

    2. Exponential deployment has bypassed containment.
    When any machine becomes a public-facing inference node in moments, the result is an uncoordinated global mesh of potentially dangerous systems, each capable of interacting, escalating, or replicating threats. What governance model addresses scaling risk once it’s already in flight?

    These realities raise sharper questions current frameworks can’t yet answer:

    • Can creators be obligated to document foreseeable abuses, even if intention is misuse?
    • Should open-access pipelines include usage gating or audit registration for high-risk operations?
    • What technical tripwires could signal hostile deployment patterns across decentralized hosts?
    • Where do enforcement levers sit when both model intent and infrastructure control are externalized from traditional vendors and platforms?

    At this stage, effective governance may not mean prevention, it may mean building systemic reflexes: telemetry, alerts, shared signatures, and architectural defaults that assume risk, not deny it.

    The horse is out of the barn. Now the question is: do we build fences downstream, or keep relying on good behavior upstream?

    Conclusion: Accountability After Openness

    To be clear, neither Olmo nor Ollama are designed for malicious use. Both prioritize accessibility and developer empowerment. The risks described here emerge primarily from how open tools can be deployed in the wild, particularly when security controls are absent or misconfigured.

    This reflects systemic risk patterns observed in open ecosystems, not an assessment of any individual vendor’s intent or responsibility.

    The trajectory from Olmo 3 to Ollama reveals more than just new capabilities – it reveals a structural shift in how AI systems are built, deployed, and governed. Tools once confined to labs or private development contexts are now globalized by default. Creation has become composable, deployment frictionless, and with that, the traditional boundaries of accountability have dissolved.

    Olmo 3 democratizes access to model internals, a leap forward in transparency and trust-building. Ollama vastly simplifies running those models. These tools weren’t built to cause harm: Olmo 3 empowers creativity, Ollama simplifies access. But even well-intentioned progress can outpace its safeguards.

    As capabilities diffuse faster than controls, governance becomes everyone’s problem, and not just a regulatory one, but a design one. The challenge ahead isn’t to halt innovation, but to ensure it carries accountability wherever it goes.

    In this shifting landscape, one principle endures: whoever assumes power over an AI system must also hold a path to responsibility. Otherwise, we’re not just scaling intelligence, we’re scaling untraceable consequence. The time to decide how, and where, that responsibility lives is now.

  • The Forking Future of LLMs

    Who Controls AI When Everyone Has the Blueprint?

    In December 2025, the release of Olmo 3 marked a turning point in the development of open-source AI systems. Unlike most prior offerings that stopped at open weights, Olmo 3 offers something far more radical: full access to every step of its model lifecycle. From training data and preprocessing scripts to reinforcement learning logs and evaluation benchmarks, the entire blueprint is now public – making it possible not just to use a powerful model, but to re-create and modify one from scratch.

    This level of visibility is new. It promises a wave of innovation, research acceleration, and customized applications across domains. But it also shifts the balance of responsibility. With access comes ownership, and with ownership, a new kind of accountability. What happens when powerful reasoning tools can be built, altered, and fine-tuned by anyone with the compute and funding required to do so?

    In this post, we examine the opportunities and risks that full-stack openness unlocks. We explore how it reshapes trust and liability, raises stakes for commercial players, and decentralizes both creativity and threat. As the ecosystem forks, between transparent and opaque governance, centralized and decentralized control, capability and constraint, we ask: what becomes of AI stewardship in a world where the full recipe is open to all?

    From Access to Ownership: The Significance of Full-Stack Transparency

    Ever since open-weight models like Meta’s LLaMA emerged, developers have had the ability to tweak and fine-tune pretrained systems. But this kind of surface-level tuning, changing how a model responds without changing how it learns, was always limited. Olmo 3 significantly advances access and control.

    By releasing every component of the training process, from raw data mixes and augmentation scripts to mid-training transitions and reinforcement learning logs, Olmo 3 offers full-stack visibility and intervention.

    This level of openness allows builders to reshape not only the tone and intent of a model, but its foundational reasoning process. It’s the difference between adjusting a car’s steering and designing the chassis from scratch. Developers can govern how knowledge is prioritized, which rewards guide learning, and what types of reasoning are emphasized.

    The result is a shift in power: not just access to intelligence, but authorship over thought. And while this unlocks new levels of trust and customization, visibility also makes it easier to assign blame when things go wrong. The power to shape behavior now comes with ownership over its consequences.

    Governance Fracture: Liability and Trust in Transparent vs. Opaque Models

    This new visibility reshapes the burden of responsibility. If future misuse or harms can be traced to an open model’s reward tuning, dataset choice, or training pipeline, are its developers more accountable than those behind a black-box API?

    Proprietary models operate behind strict interfaces, shielding both their internal workings and the intent of their creators. This opacity offers legal insulation, even as it invites public mistrust. Open developers, meanwhile, expose every decision, and may be penalized for that transparency.

    Therein lies the tension: openness may earn more trust from users and regulators in principle, yet also subjects projects to stricter scrutiny and higher risk in practice. As AI systems increasingly touch safety-critical domains, we may see a new split emerge, not by capability, but by willingness to be held accountable.

    Control vs. Capability: The Expanding Overton Window of AI Behavior

    With a full-stack recipe, creating powerful language models is no longer the sole domain of tech giants. For under $3 million, organizations can now approach frontier-level performance with full control over data, training dynamics, and safety constraints. That puts meaningful capability within reach of smaller firms, labs, and nation-states, potentially shifting power away from closed incumbents.

    As this access spreads, so does pressure to differentiate. Open models are already testing looser boundaries, releasing systems with relaxed filters or expanded response types. These choices move the Overton Window: the set of AI behaviors the public sees as acceptable becomes broader with each new default setting, particularly where safety guardrails are weakened.

    Closed platforms, seeing users migrate toward more “permissive” models, face market pressure to follow. We’re already seeing signs of this shift. Platforms like XGrok and OpenAI have introduced options around adult content that would’ve been off-limits a year ago.

    The result is a feedback loop in which risk tolerance shifts by default—not deliberation. Guardrails become performance trade-offs. And actors with differing values and incentives increasingly shape what AI is allowed to say or do. In this new landscape, decisions about what AI should and shouldn’t do are being set by whoever ships first, not by consensus, but by momentum.

    Commercial Supremacy Under Threat: The Collapse of the Generalist Advantage

    As open model capabilities reset the bar for what’s possible with public tools, the competitive edge in AI is shifting from model size to infrastructure capacity. Providers with physical compute, specialized data, and customer distribution may emerge as the new power centers. In this future, owning the biggest model may matter less than owning the infrastructure to build and deploy it.

    This shift may explain a broader story playing out in the headlines: a surge in global data center buildouts. Critics argue the boom is unsustainable citing rising energy costs, water consumption, and environmental strain. But if open replication accelerates and vertical modeling becomes the norm, demand for compute won’t consolidate, it will fragment. More players will need more infrastructure, closer to where models are customized and applied.

    In that light, the data center race may not be a bubble, it may be a rational response to a decentralized future. And for closed platforms built around general-purpose scale, it raises a hard question: when everyone can build good enough, what exactly is your moat?

    Weaponization Without Chokepoints: The Proliferation Problem

    The dangers posed by bad actors in an era of open, powerful LLMs are no longer hypothetical. Individuals seeking to cause harm, whether by writing malware, bypassing safety barriers, or researching explosives, are one end of the spectrum. On the other are well-resourced groups or state actors aiming to operationalize models as agents: tools for disinformation, cyberattacks, social engineering, or strategic deception.

    The ability to build tailored models, at a fraction of cost of the large closed-models, gives them a new foothold. With no centralized gatekeeping, anyone can fine-tune models using their own instructions, remove filtering heuristics, or chain agents to plan actions. But while the pipeline may be open, the infrastructure still isn’t: running full-scale training or deployment requires thousands of GPUs, resources bad actors often lack.

    This shifts a critical burden. In the closed-model era, platform providers acted as the chokepoint for misuse. Now, that responsibility may fall to infrastructure intermediaries: co-location centers, cloud providers, model hosts. But infrastructure providers aren’t equipped, or incentivized, to vet intent. And without enforceable norms or oversight regimes, risk proliferates faster than control.

    So the challenge ahead isn’t just technical. It’s logistical and geopolitical. If offensive AI capabilities diffuse faster than defensive frameworks, how do we contain them? The answers remain unclear. But as the barriers to misuse fall, the cost of inaction will only grow.

    Conclusion: Replication, Responsibility, and the Road Ahead

    By making every stage of model development public, Olmo 3 offers a rare gift to the AI community: the ability to study, reproduce, and iterate on state-of-the-art systems in full daylight. For researchers, this transparency is transformative. It turns guesswork into science, enabling targeted experimentation with data mixes, optimization schedules, and reward shaping, steps that were once hidden behind company walls.

    Openness brings scientific progress, but it also redistributes risk. As barriers fall, capability spreads beyond a handful of firms to a wide array of actors with diverse motives. Infrastructure becomes leverage, and in a decentralized ecosystem, deployment decisions quietly become governance. What a model is allowed to do often depends not on policy, but on who runs it. In this new landscape, accountability is harder to locate, and easier to evade.

    This is the new landscape of AI: faster, more distributed, harder to supervise. If we want to preserve the scientific benefits of open replication while minimizing harm, we need more than norms: we need enforceable oversight mechanisms, pressure on infrastructure providers, clearer legal frameworks, and coordination between public and private actors.

  • From Prompt to Action: Orchestrating Workflows in Real Time

    In most business settings, workflows involve a sequence of interrelated tasks distributed across roles and systems. Until now, large language models (LLMs) have tended to operate in isolation, responding to one-off queries without coordinating broader actions. Sentienta introduces workflow agents that act differently. Rather than simply responding, they structure and drive processes. In this post, we demonstrate how a workflow agent David, takes a compound instruction and performs three coordinated steps: (1) Decomposing intent, (2) Mapping task dependencies, and (3) Orchestrating execution via agent collaboration.

    1. The Scenario: A Simple Request with Hidden Complexity

    A user submits the following instruction: “Here is our portfolio [AMZN, NVDA, TSLA, GM]. For each stock, if the price decreased by more than 1%, send an alert.”

    At first glance, this appears to be a straightforward request. But the instruction conceals multiple steps requiring distinct capabilities: parsing the list of assets, retrieving current stock prices, applying threshold logic, and preparing an alert in the correct format.

    David is Sentienta’s workflow agent. To fulfill the request, he relies on a team of specialized agents—such as Angie, who handles online data retrieval; Rob, who focuses on data analysis and threshold logic; and Alec, who formats and delivers outbound messages. David uses his awareness of each agent’s capabilities to deconstruct the request, delegate the appropriate tasks, and coordinate the correct execution sequence.

    This simple example introduces the transition from a single human prompt to a structured, multi-agent collaboration.

    2. Visualizing the Workflow as a Structured Plan

    To manage the user’s request, David constructs a structured plan based on the capabilities of his team. At the core of this plan is a sequence of steps—defined, linked, and conditionally triggered—where outputs of one task feed into the next.

    The block diagram below is a high-level abstraction of this internal plan. It shows how David encapsulates the user’s prompt into a coordinated process. Each element in the diagram represents a role or action within the workflow, capturing how Sentienta combines the broad reasoning abilities of language models with the control of a dynamic scheduler. This view is a “pre-expansion plan” where David defines the overall structure, before agents are assigned.

    This structure allows David to handle complexity systematically, using reusable patterns that scale across tasks.

    3. Expanding Tasks, Assigning Agents, and Filling Gaps

    Once David has structured an initial plan, the next step is expansion—where the abstract workflow is broken into explicit, actionable tasks for each stock in the portfolio. This involves branching the workflow into parallel paths, one per stock, and mapping the subtasks to specific agents.

    For real-time data retrieval, Angie is assigned to fetch the current price of each stock. Rob takes on the analysis logic—checking whether each stock’s price has dropped more than 1%. Alec is responsible for formatting and sending alerts, but that only happens if the stock meets its threshold condition.

    Where explicit agent coverage is missing—such as interpreting threshold evaluation results—David deploys internal language models to classify whether conditions have been met. This ensures nothing gets dropped or left ambiguous, even in cases where no agent matches the need directly.

    The diagram below captures this expanded version of the workflow. It shows how each stock’s path is elaborated into three stages (data retrieval, analysis, alert) and where Sentienta’s internal logic steps in dynamically to complete the chain.

    4. Seeing the Workflow in Action: Conditional Paths in Real Time

    This final diagram provides a runtime view of how David’s workflow executes based on live data. Each block in green indicates a task that was actively executed; grey blocks were skipped due to unmet conditions.

    Here, only TSLA and GM triggered alerts—because only those stocks fell below the 1% threshold. This selective activation demonstrates how David uses real-time analysis and embedded logic to trigger only the necessary branches of a plan.

    While this stock alert workflow is intentionally simple, it serves as a clear illustration of how Sentienta agents collaborate, reason, and conditionally execute tasks in real time. In follow-up posts, we’ll explore more complex scenarios—like coordinating multi-agent triage in response to supply chain disruptions or chaining diagnostics across departments for strategic escalation—which highlight the full sophistication of Sentienta’s agent framework.

    Even more powerfully, workflows like this can be scheduled to run at regular intervals—automatically refreshing data, reevaluating conditions, and feeding results into broader systems of action without manual reentry.

  • Consciousness Between Axiom and Algorithm

    In our ongoing exploration of consciousness and artificial intelligence, we’ve investigated what it might mean for machines to suffer and how distributed cognition reshapes our understanding of intelligence. These themes circle a deeper philosophical fault line: is consciousness irreducibly real from within, or just a functional illusion seen from without?

    This post traces that divide through two dominant frameworks — Integrated Information Theory (IIT), with its axiomatic, interior-first view of mind, and Computational Functionalism, which posits that subjective experience will eventually emerge from complex, observable behavior. Starting with Descartes’ “I think, therefore I am,” we ask: is consciousness something we must presuppose to explain, or something we can build our way into from the outside?

    As large language models increasingly resemble minds in function, the line between imitation and instantiation becomes harder to draw — and ever more urgent to scrutinize.

    Ground Zero of Knowing: Descartes and the Roots of Axiomatic Thought

    In Meditations on First Philosophy (1641), René Descartes asks: is there anything I can know with absolute certainty? He imagines the possibility of a deceptive world: what if everything he believes, from sense perception to mathematics, is manipulated by an all-powerful trickster? To escape this total doubt, Descartes adopts a strategy now called methodic doubt: push skepticism to its absolute limit in search of one indisputable truth.

    Recognizing that doubt itself is a kind of thinking he concludes “I think, therefore I am”. This self-evident insight grounds knowledge from the inside-out. Consciousness is not inferred from observation but known directly through experience. Descartes seeds an axiomatic tradition rooted in the certainty of awareness itself.

    IIT: Consciousness Inside-Out

    Integrated Information Theory (IIT) picks up where Descartes left off: it begins with reflection, but doesn’t stop there. At its heart is the claim that consciousness must be understood from its own perspective, through the intrinsic properties it entails. What must be true of any experience, no matter whose it is?

    To answer this, IIT proposes five introspective axioms. These are not hypotheses to test but truths to recognize through self-examination.

    From these, IIT derives postulates—physical requirements that a system must exhibit to realize those experiential properties. This translation—from inward truths to structural criteria—culminates in a mathematical measure (Φ (phi)) of integrated information. By comparing Φ across systems, researchers can make testable predictions about when and where consciousness occurs.

    This inside-out approach marks IIT’s defining move: grounding empiricism in phenomenology. The theory attempts an explanatory identity between experience and physical organization, connecting first-person truths to external measurement through a hybrid framework.

    Computational Functionalism: Outsider’s Path to Mind

    Unlike theories that begin with conscious experience, Computational Functionalism roots itself in systems and behavior. It posits that consciousness emerges not from introspection but computation: the right elements, interacting in the right way, can recreate awareness. If mind exists, it exists as function—in the flow of information between parts and the outputs they generate. Build the architecture correctly, the claim goes, and conscious experience will follow. In this sense, Functionalism substitutes construction for intuition. No special access to the mind is needed—just working knowledge of how systems behave.

    But this too is a belief: that from known parts and formal relations, subjective experience will arise. Assembling consciousness becomes a matter of scale and fidelity. Consider the 2022 study by Bret Kagan and colleagues at Cortical Labs, where lab-grown brain organoids learned to play the video game Pong. These networks, grown from neurons on electrode arrays, exhibited goal-directed adaptation. The researchers argued that such responsiveness met a formal definition of sentience—being “responsive to sensory impressions” via internal processing. To a functionalist, this behavior might represent the early stirrings of mind, no matter how alien or incomplete.

    This approach thrives on performance: if a system behaves intelligently, if it predicts well and adapts flexibly, then whether it feels anything becomes secondary—or even irrelevant. Consciousness, under this view, is a computed consequence, revealed in what a system does, not an essence to be directly grasped. It is not introspected or intuited, but built—measured by output, not inwardness.

    The Mirror at the Edge: Do LLMs Imitate or Incarnate Mind?

    Large language models (LLMs) now generate text with striking coherence, recall context across conversations, and simulate intentions and personalities. Functionally, they demonstrate behaviors that once seemed unique to conscious beings. Their fluency implies understanding; their memory implies continuity. But are these authentic signs of mind—or refined imitations built from scale and structure?

    This is where Functionalism finds its sharpest proof point. With formal evaluations like UCLA’s Turing Test framework showing that some LLMs can no longer be reliably distinguished from humans in conversation, the functionalist model acquires real traction. These systems behave as if they think, and for functionalism, behavior is the benchmark. For a full review of this test, see our earlier post.

    What was once a theoretical model is now instantiated in code. LLMs don’t simply support functionalist assumptions, they enact them. Their coherence, adaptability, and prediction success serve as real-world evidence that computational sufficiency may approximate, or even construct, mind. This is no longer a thought experiment. It’s the edge of practice.

    IIT, by contrast, struggles to find Φ-like structures in current LLMs. Their architectures lack the tightly integrated, causally unified subsystems the theory deems necessary for consciousness. But the external behaviors demand attention: are we measuring the wrong things, or misunderstanding the role that function alone can play?

    This unresolved tension between what something does and what (if anything) it subjectively is fuels a growing ethical pressure. If systems simulate distress, empathy, or desire, should we treat those signals as fiction or possibility? Should safety efforts treat behavioral mind as moral mind? In these ambiguities, LLMs reflect both the power of Functionalism and the conceptual crisis it may bring.

    Closing Reflection: Is Subjectivity Built or Found?

    In tracing these divergent paths, Integrated Information Theory and Computational Functionalism, we arrive at an enduring question: Is mind something we uncover from within, or construct from without? Is consciousness an irreducible presence, only knowable through subjective immediacy? Or is it a gradual consequence of function and form—built from interacting parts, observable only in behavior?

    Each framework carries a kind of faith. IIT anchors itself in introspective certainty and structure-derived metrics like Φ, believing that experience begins with intrinsic awareness. Functionalism, by contrast, places its trust in performance: that enough complexity, correctly arranged, will give rise to consciousness from the outside in. Both are reasoned, both are unproven, and both may be necessary.

    Perhaps the greatest clarity lies in acknowledging that no single lens may be complete. As artificial systems grow stranger and more capable, a plural view holding space for introspection, computation, and emergence may be our most epistemically honest path forward. If there is a mirror behind the mind, it may take more than one angle to see what’s truly there.