Engineering team culture matters more in the agentic era

As agents take on more of the actual coding, a team’s culture becomes the thing that decides whether agents deliver impactful work or just burn tokens. The standards people hold, the ownership they take, the questions they ask of a confident-looking change: agents amplify all of it, for better and for worse. Hand powerful tools to a team with weak habits and you get more bad work, faster. Ownership stays with people The single most important habit is refusing to let accountability blur. When an agent writes something, a person still owns it: understanding it, accepting it, and answering for it later. Teams that hold this line keep their standards intact as volume grows. Ownership is a cultural choice before it’s a process one. It shows up in whether an engineer feels responsible for an agent’s output the way they would for their own, and leaders set that tone by how they respond when agent-assisted work goes wrong. “The model did it” can’t be an acceptable answer.  Reward the careful moments, and learn from them Make it safe, and even respected, to be slow in the places that warrant it. An engineer who pauses to dig into a confident-looking change and finds the flaw in it should be held up as doing the job well. What a team rewards is what it gets more of, and a careful pass that goes uncredited is the first thing to disappear under pressure.  The teams that compound go one step further and turn those catches into shared knowledge. A confident-but-wrong output that one reviewer caught is worth far more to the whole team than to that one person. Circulating the near-misses and the places agents reliably go wrong is how a team builds a shared sense of where to trust the work and where to look harder, so the same mistake doesn’t have to be caught twice. Judgement is the skill worth growing As agents absorb more of the mechanical work, the human contribution shifts to the things they can’t do well: framing the problem, setting the constraints, knowing when an answer is wrong even when it looks right. A healthy culture treats these as skills to develop on purpose, not traits people happen to have. That has real implications for how teams grow their people. If juniors never write the boilerplate agents now handle, they need other ways to build the judgement that used to come from it: reviewing agent work with a senior, being handed real ownership early, and getting honest feedback on the decisions they make rather than just the code they produce. That exchange runs both ways. A senior who walks a junior through why an output is wrong sharpens their own judgement in the process, and the pairing keeps the whole team’s instincts current. Transparency by default The teams that trust agent work are the ones who can see it. When decisions, context, and the reasoning behind a change are written down and shared rather than living in one person’s chat history, the whole team can build on each other’s work instead of quietly duplicating or contradicting it. The strongest teams go further and give that shared context a home the tools themselves can read, so the standards and history a team relies on live in a connected layer of work rather than in any one person’s head. Transparency is what turns a group of people each working with their own agents into a teamworking toward one thing. Culture is the part you build You can add more agents anytime. The norms that make them worth having take longer and matter more: ownership that stays with people, skepticism that’s welcomed, judgement that’s grown deliberately, and work that’s visible by default. Build those and every tool you adopt compounds on top of them. See how leading engineering organizations are building the culture and habits that make agents worth having at jira.dev.

Overview

The task an agent picks up starts somewhere messy: a message in a channel, a line in a planning doc, a bug buried in a customer thread. Most of the time it also builds on work the team already did. Turning that raw signal into a task an agent can act on, with the right context carried forward, is where most of the output quality is decided. This is context engineering: the work of shaping intent and context into something an agent can build against. For years it didn’t need designing. An engineer picked up a vague ticket and filled the gaps from experience: they knew the system, knew who to ask, and knew which unwritten constraints applied. The ambiguity got resolved quietly on the way to writing the code. An agent has none of that. It builds exactly what the task describes, and it fills gaps with guesses rather than judgment. Without the right context, code gets generated faster and productivity still takes a hit, because the wrong thing got built quickly.  Ambiguous in, expensive out  When a poorly formed task reaches an agent, the cost doesn’t show up right away. The agent produces something plausible, the work moves forward, and the mismatch between what was meant and what was built surfaces later, in review or after it ships. By then it’s more expensive to unwind than it would have been to specify correctly at the start. Across a team running many agents, vague work compounds faster than any reviewer can catch Context is a design problem, not a discipline problem If the fix is just to write better tickets, that treats a structural gap as a personal failing, and it doesn’t holdup when work originates in a dozen places at once. The organizations getting ahead treat context as something to build, so that turning a raw signal into agent-ready work is a repeatable step rather than a task on individuals’ plates. In practice that means you can: Give raw signal one place to land. When an idea can come from a chat message, a document, or a support conversation and be captured as a task in the same system where it will be tracked and acted on, the intent survives the trip. Make the task carry its own context. A well-formed task states what outcome it wants, what constraints apply, and what “done” looks like. On top of that, the strongest setups also let an agent draw on the surrounding body of work, the related decisions and prior tasks, so it inherits the situational awareness an engineer would have brought in without being told. Close the gap while the intent is fresh. The moment to resolve ambiguity is when the task is created, while the person who understands it is still in the loop, not after an agent has acted on the unclear version. Every finished task is the next task’s starting point This isn’t a factory line where every task is the same. Each finished piece of work feeds more context into the next, and the leader’s job is to build the machine that captures it. Work comes in, an agent acts on it, and the result becomes part of the ground the next task stands on. When an agent finishes, the summary of what it did belongs back in the same system the work was tracked in, attached to the thing it acted on, available to the next person or agent who touches that area. Do that consistently and the context compounds: each finished task leaves the ground clearer than it found it, so the next task arrives with more to build on and needs less repair. What this means for leaders Investing in agentic engineering means investing in context: clear, context-rich tasks produce output that reflects what the team intended, while vague ones produce motion that has to be corrected. The job isn’t to write better tasks one at a time. It’s to build the system that turns every finished task into context for the next one, so the work gets easier as it compounds. See how leading engineering organizations turn raw signal into agent-ready work at jira.dev.

Vendor consolidation is sold as discipline. Fewer vendors, simpler architecture, better pricing through volume, one throat to choke when something breaks. Every one of those benefits is real on paper. The problem is that the biggest cost of consolidation rarely appears on the slide the procurement team uses to sell it internally, and it does not show up on the savings tracker until the first renewal cycle after the ink is dry. Within CIO Mastermind’s topic-specific cohorts, which I sometimes facilitate, I hear a version of the same story often enough to recognize the pattern early. A consolidation program gets pitched against a strong multi-year savings target. The first year or two look good. Then a renewal arrives, the remaining vendor prices to the switching cost the company just built for itself, and a meaningful share of the projected savings quietly erodes. The company still ends up with fewer vendors. It does not always end up with the leverage the original business case promised. What consolidation actually removes What consolidation actually removes is competitive pressure on the vendor you keep. That is the part most business cases leave out. Going from a dozen vendors in a category down to three or four feels like simplification, and it is. It is also a message to the vendors you kept about how expensive it would be for you to leave. The fewer live alternatives you maintain, the more accurately a vendor can price to your captivity rather than to the open market. A consolidation deck typically shows how many vendors are being reduced. It rarely shows how many of the remaining vendors could credibly be replaced inside a reasonable switching window. That second slide is the one worth building before the program starts. That capability is often missing. Procurement teams are not being dishonest when they leave that slide out. Their incentive is to close the program and book the savings target, and the pain of a diminished market shows up two or three years later, on someone else’s dashboard. By the time the first hard renewal arrives, the people who built the original business case have often moved to a different project entirely, and the CIO who is still in the seat is the one negotiating from the position the program created. The condition that decides the outcome Consolidation programs succeed or fail on one question, and it has to be answered honestly before the program starts. Can you walk from this vendor at renewal? Not in theory. Not with twelve months of migration work. At renewal, inside the window the contract gives you, with a credible alternative that has been exercised recently enough to be real. If the answer is yes, the vendor will price to keep you. If the answer is no, the vendor will price to what you can absorb. Consolidation that leaves you unable to walk is a long-dated price increase with a celebratory kickoff meeting, dressed up as a savings program. Contract language deserves particular scrutiny here, because it is where a lot of the false confidence comes from. Multi-year agreements often include price increase caps that look protective at signing. Those caps are usually written around the product as it exists at signing. Vendors may repackage functionality into new or higher-priced tiers, leaving the contractual cap covering less of what the company actually needs. A cap that looked airtight in the negotiation can end up covering a shrinking share of what the company actually pays for at renewal. CIO.com has covered the leverage problem for years, including a piece on how to increase your renegotiation leverage with vendors that frames the handcuff problem directly. The advice in articles like that one is sound. The hard part is applying it in the middle of a consolidation program, when the procurement team is telling you that keeping alternatives warm is wasteful and the CFO is asking why the savings number is dropping. The CIOs who hold their leverage tend to do one thing differently. They keep one credible alternative warm in every major category they consolidate, even after the primary vendor is chosen. Warm means more than a name on a shortlist. It means a live relationship with the alternative’s account team, some recent proof of concept, and at least one internal team that has actually touched the alternative’s platform. That readiness carries a real cost. Maintaining it may cost far less than an uncontested renewal can quietly take away. The number that actually matters to the CFO Most consolidation programs get measured against a single number: the savings projected in year one of the business case. That number rewards aggressive consolidation and quietly punishes the CIO who keeps an alternative warm, because the carrying cost of that alternative shows up immediately while the protection it buys only shows up at the next renewal, two or three years later. Judged against a one-year number, the cautious approach always looks worse. The number worth tracking instead is the savings figure three years out, measured against what the business case originally promised. That is the number an aggressive consolidation program tends to miss once a full renewal cycle has run its course, and it is a fairer test of whether the program actually worked. It also reframes the conversation with the CFO. A carrying cost presented as insurance against a specific, quantifiable renewal risk is a different ask than a carrying cost presented as overhead, and it tends to get a different answer. What to do if you inherited the problem Most of the CIOs I talk to are not starting a consolidation program. They inherited one. They sit down in a seat where the leverage is already gone and the next renewal cliff is six or nine months out. If that is where you are, the fastest way back to a real negotiating position is not to rebuild leverage everywhere at once. That approach takes years and asks the CFO to fund carrying costs across the entire portfolio before there is any evidence it will pay off. Pick one category instead, ideally not the largest one but the one where a credible alternative can be stood up fastest, and rebuild it inside twelve months. Speed matters more than scale here. A live proof of concept in a smaller category, exercised recently enough to be real, does more for your negotiating position than a partially built case in a larger one. One proof that you can still move part of the portfolio changes the conversation at every other renewal table. A vendor who knows you have already done it once treats the next renewal differently than a vendor who has only heard you claim you could. The second you cannot walk, the price stops being yours to negotiate. Most consolidation programs remove your ability to walk as their first move, and most CIOs do not realize they have given it up until the next renewal arrives and reminds them.

Enterprises have built their data systems for humans, but AI agents need a whole new infrastructure. Separate research from Cloudera and Google/MIT found that, not surprisingly, there is fervent enterprise interest in AI agents, but underlying infrastructure struggles to keep up. Deployments continue to be hampered, sometimes even abandoned, largely due to issues with data access, context, and governance. “Enterprise adoption of agentic AI is on the cusp of an extraordinary acceleration,” the Google/MIT report noted. “As organizations look to scale agentic AI across the enterprise, they cannot ignore their data systems.” Resolving data bottlenecks, then, should be an immediate priority. Projects delayed, inaccessible data Cloudera’s report, created in partnership with Wakefield Research, describes the need for a “great AI re-architecture.” Of the 1,500 enterprise architects and cloud infrastructure leads surveyed, a stunning 95% said they had delayed or cancelled AI projects, in some cases six or more, in the past year, due to issues with data governance, compliance, or regulatory issues. A wide majority also reported that AI integrations have changed their data storage and architecture practices, AI workloads have increased infrastructure costs, and current data architecture requires a “significant overhaul” to meet AI goals. “Even if enterprises are ready to use AI, many are coming to the realization that the foundational infrastructure it relies on is not,” the report noted. Similarly, more than half of the 300 IT execs and heads of product, IT, data, and AI responding to the Google/MIT survey said they have paused or delayed the deployment of AI agents to address foundational data issues, such as siloes or lack of context. Further, more than half reported that legacy data systems are preventing them from scaling agentic AI and are having a “significant negative impact” on their AI ROI. High latency has also hampered AI from making decisions at “high velocity.” “To make good decisions and take effective action, agentic systems need a data foundation that is multimodal, context-aware, and instantly available,” the report noted. “Legacy data systems struggle to meet these demands, ultimately compromising AI trustworthiness.” Google and MIT identified several reasons that enterprises struggle to deploy AI agents, most notably: Entrenched siloes: Data sits in disconnected systems, or is “pocketed away” in different departments with no integration layer; it could also be in outdated formats, old management platforms or logs, or on obsolete IoT devices. Difficult-to-access data: “Dark” or unstructured data is contained in different formats like images, video, or PDFs. Insufficient access to real-time data: Legacy batch processing architectures can make in-time action a challenge. Lack of context: Agents often receive basic metadata rather than enterprise-specific semantics, so they struggle to make relevant connections or suggestions. “Without this deep understanding, data cannot be highly relevant to specific use cases,” the report noted. ‘Data leaders’ versus ‘data laggards’ This is not to say that enterprises aren’t deploying AI; quite the contrary. Nearly all respondents (98%) to the Google/MIT survey are already using agentic AI or plan to soon. One in 10 is using it widely and nearly three quarters have deployed it in a limited fashion. The most common uses for AI agents right now are in customer service (routing requests and resolving issues), IT systems management (managing user access and incident response), and IT security (anomaly detection and threat scanning). In the near future, the survey said, enterprises also plan to use AI agents in HR, finance, and supply chains. “It is easy to understand why companies are eager to put AI agents to work,” the report noted. Agents can supercharge productivity and efficiency so employees can turn to more strategic work. The enterprises seeing the most success are what Google and MIT refer to as “data leaders,” those that give AI systems access to more than 70% of their data. “Data laggards,” by contrast, share just 30% or less of their data with AI. Interestingly, 100% of data leaders say their agents make “mostly” or “consistently” accurate and relevant decisions, while just 22% of data laggards say they have that trust. Agents need what the report calls “frictionless access” to operating systems, multimodal data, and context, helping them understand how data maps to different teams’ goals. “The most important initiative to enable scaling among all respondents is improving access to structured and unstructured data for AI agents.” To successfully scale agents, the report recommended that enterprise leaders prioritize several data initiatives. First, improve access to data; discover, inventory, and classify data, both structured and “dark”/unstructured. After governance principles are applied, information can then be extracted and connected to AI agents. Next, “put a premium on context” by giving agents enterprise-specific data. Replace batch processing with streaming and event-driven pipelines as well. Finally, think AI-native. “AI-native systems are designed to operate in an AI environment and built from the outset to leverage AI for data management and decision-making,” the report noted.   AI needs multimodal cloud environments AI needs a lot of data that is often spread across on-premises systems and cloud, SaaS, and edge environments. In fact, 97% of respondents to Cloudera’s survey said they move data between environments monthly, and nearly one-third do so daily. However, nearly three-quarters (73%) said AI integration makes data governance more complex. “Enterprises had good governance systems when humans were the only ones accessing data manually,” the report noted. “But when thousands of agents provide support to employees, customers, or partners the story changes and governance requires another dimension.” This makes private AI and data sovereignty critical, Cloudera said. Enterprises should have a data foundation that is unified and provides control over 100% of organizational data, wherever it resides. They must also think about where AI workloads run, while still maintaining control over sensitive data and keeping cost controls and flexibility in mind. One notable trend Cloudera uncovered is a “resurgence” of on-premises and private cloud environments. Over the last 12 months, 66% of respondents moved AI workloads from public cloud back to on-premises or private cloud environments. And 25% said they plan to place more emphasis on a hybrid-first approach, 24% said they are planning to increase on-premises spend, and 22% plan to increase edge spend. “IT leaders are putting more emphasis on moving workloads to the environments that they are best suited for, based on performance, cost, latency, governance, availability, and accessibility,” the report stated.

Some of the first credible evidence of artificial intelligence’s impact on the labor market has just been published and, at first glance, it appears to tell a concerning story for women. Researchers at Stanford University’s Digital Economy Lab, analyzing payroll data from millions of American workers, found that employment growth has been weakest among early-career professionals in occupations with the greatest exposure to AI. Among those workers, young women are experiencing slower employment growth than men. It might seem AI is creating a new gender divide. But the researchers point to a different explanation. Young women are disproportionately concentrated in occupations built around routine cognitive work—the very tasks generative AI performs increasingly well. Rather than creating a new inequality, AI may be resurfacing one that has existed for decades. Disproportionate disruption Women have often borne a disproportionate share of economic disruption. They remain overrepresented in many administrative, clerical and support occupations that have been repeatedly reshaped by new technologies. Long before today’s AI debate, the Nobel Prize-winning economist Claudia Goldin argued that many of the most persistent gender differences in the labor market didn’t reflect a gap in ability or ambition, but rather revealed the effects of the way professional work had been designed. She observed that many of the highest-paying careers simply rewarded long hours and constant availability more than productivity itself. The binding constraint was time, not talent, and women were often at a disadvantage because they typically managed the greater share of household and childcare responsibilities. These personal commitments left working women without the scheduling flexibility that is needed for advancement in the most lucrative jobs. The problem, then, is not technology, but rather the way work is organized. A case study I encountered this firsthand while serving as chief strategy officer at NCSoft, one of Korea’s leading gaming companies. We were losing exceptional employees, particularly women, whose careers often became more difficult to sustain after becoming parents, and wanted to find a way to retain them. One of the obvious solutions was to provide childcare benefits to parents. But the more we examined the problem, the more we realized better benefits alone weren’t enough. A daycare that opens after the work day begins does not help a parent who must be at work by 9. One that closes before dinner makes it difficult to attend an evening meeting or build the informal relationships that often accelerate careers. And even when children are safe and well cared for, many parents still carry guilt, worrying they are falling short in supporting their children’s early development. So with this in mind, we built a daycare within the company that was designed around the realities of professional work. It opened at 8 a.m. and remained open until 9 p.m. The curriculum was built around early childhood research on cognitive development, so parents could drop off their children and leave for work, confident they were learning, not merely being supervised. We developed our own curriculum, management systems, and operating model to ensure childcare was not just an employee benefit bolted onto the company, but instead embedded into its infrastructure. Our strategy worked. Not only did the women we worried about losing stay, they advanced at the company. The lessons here went further than childcare. It made me realize that a disparity we’d previously seen as an inevitable norm was actually the result of the design of the workplace, something we could change to better serve employees and the company at large. If we changed that design, we could change the outcomes too.  A broader opportunity What I saw inside one company, AI is now surfacing across entire industries, revealing longstanding weaknesses in the way modern work is organized, with implications that go far beyond gender equality. The result is an opportunity for organizations that extends past automation. History suggests that the greatest impact of general-purpose technologies comes not from automating existing systems but from redesigning them entirely. Electricity transformed manufacturing only after factories reorganized production around it. The internet transformed business only after companies redesigned how information flowed, decisions were made, and customers were served. AI offers the same opportunity. Organizations could rethink entry-level work from the ground up. Rather than asking junior employees to devote their time to routine cognitive tasks, they could redesign those roles around the judgment, relationships, and specialized expertise that become more valuable with experience. By developing those capabilities earlier, employees could take on greater responsibility sooner. As advancement becomes tied less to time spent completing routine work and more to the value people create, the premium placed on constant availability could also begin to erode, creating more equitable pathways to advancement. Ultimately, whether AI narrows or widens existing inequalities will depend less on the technology itself than on the choices organizations make about the work surrounding it. This is why the Stanford research is not simply an early warning about who is most exposed to professional penalties due to AI. It is also a reminder that the labor market being disrupted was never a level playing field to begin with. If organizations use this technology only to automate existing jobs, they may reinforce those inequalities. But the companies that treat AI as an invitation to reimagine work have an opening to build systems that correct them. 

I have been writing for several months about what I see more and more as the central problem in enterprise AI. I’m seeing it not just from an academic perspective: Of course, I’m a university professor with more than 30 years of experience, but I’m also the director of innovation of an artificial intelligence startup, and that’s teaching me a whole lot of new skills. Traveling from theory to code and back, day in and day out, is proving to be an amazingly enriching journey.  First of all, we should know by now that large language models are extraordinarily capable, but they were not designed to run companies. They are great at generating answers. But organizations require other things: persistent state, formal structures, permissions, feedback loops, measurable objectives, and the ability to learn from outcomes. The more these ideas travel from essays and diagrams into working software, the clearer the problem appears. The concepts that sound convincing in prose tend to collapse when someone has to express them in code. “Memory” turns out not to be a data model. “Autonomy” means little without permissions. “Learning” is not the same thing as simply accumulating context. And “optimization,” as we all know, becomes dangerous unless somebody defines exactly what the system is being asked to optimize.  This is not simply a technical problem. It is an epistemological one: The AI industry has built Aristotelian machines. What enterprises need now is a Baconian approach.  The most powerful Aristotelian machines ever created  For more than 2,000 years, Western thought has been shaped by Aristotle’s extraordinary influence on logic and deduction. Start with premises, reason correctly from them, and jump to a conclusion.  The syllogism we study in Philosophy 101 is the classic example: All humans are mortal; Socrates is human; therefore, Socrates is mortal. If the premises are correct and the reasoning is valid, the conclusion follows.  All the large language models we know so far operate in a surprisingly similar way. They start by absorbing vast quantities of recorded human knowledge that was on the internet, transform this into vectors, and generate the most statistically coherent continuation from what they have learned. In doing so, they can reason, compare, summarize, infer, explain, and combine ideas across domains with quite remarkable sophistication.  However, they remain enclosed within the information available to them. They do not inherently observe what happens after an answer is produced. They do not test whether a recommendation worked. They do not revise their operating structure when a customer leaves, a sales campaign fails, or an apparently efficient policy causes an unexpected problem elsewhere.  Think hallucinations. When a model hallucinates, it is not necessarily malfunctioning; it is producing a plausible conclusion from imperfect premises, but without any structural mechanism to check that conclusion against reality. OpenAI’s own research connects hallucinations to next-word prediction and to training systems that reward guessing, rather than acknowledging uncertainty.  That is a profoundly Aristotelian condition.  Bacon was the one who changed the architecture of knowledge  Francis Bacon’s contribution, in the sixteenth and seventeenth centuries, was not simply to argue that observation mattered. This has already been noted by many people who had been observing the world and drawing conclusions from it long before Francis Bacon.  His deeper, and phenomenal, contribution was to place observation inside a repeatable learning structure: Formulate an idea, test it against reality, observe the result, revise the hypothesis, and repeat. His method rejected the primacy of syllogistic demonstration in favor of a process that moved from observations to principles and back again to new experiments and practical results.  The scientific revolution did not emerge because Bacon was necessarily more intelligent than Aristotle, but because the Baconian method organized intelligence in a different way. It allowed discoveries to be tested, errors to be exposed, results to accumulate, and knowledge to compound across people and generations. The decisive innovation was the loop.  This distinction is extremely important for AI. Today’s frontier models are our Aristotles: brilliant individual engines capable of extraordinary, superhuman inference. But the next step is not just to build a larger Aristotle with more parameters, more training data, and a longer context window, but to build the Baconian structure and loop around it.  Companies need experiments, not just answers   Most generative AI still operates as an open-loop system. A person asks for something, the model produces it, and the interaction ends right there.  That works extremely well for individual tasks such as drafting an email, summarizing a report, explaining a concept, generating some ideas, translating a document . . .   However, as anyone with a minimum of corporate experience can understand, companies are not collections of isolated requests. They are systems of actions and consequences. As I previously argued, enterprise AI must move from answers to outcomes, from prompts to constraints, and from copilots to systems of action.  A model may recommend changing a price, modifying a sales script, prioritizing certain customers, reorganizing a support workflow, or altering an approval process. But the quality of that recommendation cannot ultimately be judged by how persuasive it sounds. It must be judged by what happens next.  After the model’s recommendation, did conversion improve? Did churn increase? Did margins rise? Did customer trust decline? Did the new process save time in one department while creating additional work elsewhere? Every enterprise action is, whether management recognizes it or not, an experiment.  A real Baconian enterprise AI system would treat it that way. It would connect actions to outcomes, outcomes to objectives, and objectives to future behavior. It would not merely generate a recommendation, but also observe its consequences and, more importantly, learn from them.  As many are starting to realize, the unit of value would no longer be the answer; it would be the loop.  Why implementation changes the theory  This is where translating ideas into software becomes intellectually useful. As I realize when I move from academia into real-world implementation, code is much less tolerant of ambiguity than prose.  It is easy to write that an AI system should “learn from the company.” But a software architect must ask what constitutes an observation, where it is stored, which events matter, how outcomes are attributed to previous decisions, and what happens when you have multiple conflicting objectives.  It is easy to say that an agent should act autonomously. An implementation must define which objects it may access, which functions it may invoke, what it may modify, when human approval is required, and who’s going to remain accountable.  It is easy to advocate continuous optimization. But optimize for what? A customer service system rewarded for reducing handling time may learn, for instance, to terminate all conversations as fast as possible. A hiring system rewarded for retention may tend to select simple conformity. A sales system rewarded for conversion may discover techniques that work commercially, while eroding trust.  A loop can be wrong and compound, over and over again. That is why enterprise AI cannot be separated from governance. Every reward function encodes a theory of what matters, every constraint expresses an institutional decision, every permission boundary allocates authority. These are not simply engineering choices.  These are corporate choices expressed in software. The AI risk management framework from the National Institute of Standards and Technology similarly treats governance as a continuous, cross-cutting activity that must connect technical design to organizational policies, values, responsibilities, monitoring, and measurable outcomes throughout the system’s lifecycle. We are clearly well above the pay grade of our usual chatbots.  From generation to learning: The real transition  The industry continues to focus its attention on model capability: which model reasons better, codes faster, uses more context, or achieves the highest benchmark score. And those improvements matter . . . but they are just improvements in individual intelligence.  The enterprise opportunity lies somewhere else: in collective intelligence, in the architecture that coordinates models, people, data, processes, objectives, and feedback so that the organization itself becomes better at achieving outcomes. That is exactly why the model should not be the company’s durable asset. It should be the learning loop surrounding it.  While generative AI produces, Baconian AI learns. The first one creates content from accumulated premises, but the second one acts within a defined environment, observes what changed, and incorporates the result into the next decision. Feedback is all you need.  And when you think about it, this is not an incremental feature to add to a chatbot, but a different way of understanding what enterprise AI is for. Ultimately, it requires companies to become not simply “automated,” but formally represented and optimizable.  This future will not be built by eliminating the Aristotelian machine; deduction still remains enormously valuable. These large language models will help us generate hypotheses, interpret situations, propose actions, and make complex systems accessible through language. But they need to operate inside an architecture in which reality, instead of just eloquence, becomes the final arbiter.  Enterprise AI does not need another Aristotle.  It needs its Bacon. 

Key Facts

• Reported by 8 sources
• First reported: 2026-08-13 13:12:44
• Category: Engineering team culture matters more in the agentic era