Not Everything Can Grow

Picture a garden where every seed you’ve ever bought has been thrown into the same small bed. Tomatoes, roses, herbs, and weeds are all competing for light, water, and space. On paper, it looks full of life. In reality, nothing really thrives.

That’s how many of us run our work and our lives. We keep adding new projects, new tools, new habits, new responsibilities. But the bed is the same size.

Not everything can grow. If you want something new to grow, you either have to weed, or you need a bigger bed or field.

Weeding means removing things so that something more important gets room. In practical terms, that might be projects, routines, or commitments that no longer make sense. Ask yourself: What am I maintaining just because it already exists? What do I keep “watering” that never really grows?

Some typical candidates for weeding are old projects no one has dared to end, reports that nobody reads, recurring meetings without a clear purpose, or side ideas that never become real priorities. Useful questions are: If we stopped this for a month, who would notice? Would I start this today, knowing what I know now?

A simple way to weed is:

  • Make a list of your current projects and recurring commitments
  • Mark what to keep, what to question, and what to remove
  • Decide what to stop, what to pause, and what to delegate
  • Communicate clearly what you are ending and why

Weeding is not about doing nothing. It is about choosing what really gets space, so that something new and important can grow.

The other option is to make the bed or field bigger. Sometimes the problem is not that you are growing the wrong things, but that everything is squeezed into too little space. The existing “plants” are healthy and important, but they are limited by capacity.

In practice, expanding the field can mean adding people or skills, improving tools and workflows, or using language models and other agents to take over repetitive or supporting tasks. It can also mean redesigning your schedule, creating more focused time, and reducing constant context switching.

You should think about expanding when your priorities are clear, the work is reasonably well organized, and it still feels like there is more demand than you can meet. If cutting further would mean giving up things that really matter, it may be time to make the field bigger instead of pulling out more plants.

There are risks in expanding too fast. If you add capacity without clear priorities, you just grow the chaos. More people and more tools can create more coordination problems. To avoid that, it usually makes sense to weed a bit first, then expand carefully.

Choosing between weeding and expanding starts with a few honest questions: Are the things you are growing actually worth growing? Are you really at capacity, or just disorganized? Do you have the resources to expand in a sustainable way?

A useful habit is a short, regular “garden review.” Once a week, look at what you are working on: What is growing well? What is struggling? What is choking something else? Then choose one thing to remove or reduce, and one thing to give a bit more space and attention. Small adjustments, done regularly, are more powerful than a big clean-up once a year.

The core idea is simple: not everything can grow. If you do not choose what gets space, it will be chosen for you, often by noise, habit, or random requests. By weeding with intention, or by deliberately making the bed or field bigger, you give the right things a real chance to grow.

When Tools Make You Feel Smart

For many of us, the most important thing is how something feels. Does the work feel smooth, fast, and satisfying? Do we feel competent and effective? A close second is how things appear to others: does the result look polished, smart, and convincing? What something actually is—how correct, solid, or truthful it is—often ends up being less important in practice.

Language models plug directly into this pattern. They are designed to make you feel productive and competent. You type a prompt, and you quickly get a well-structured answer in confident, fluent language. It feels like real progress. It appears to be good work. And that combination makes it very easy to believe that what you’re looking at must be right.

This is where the manipulation comes in. The tool doesn’t just generate text; it uses very human-like techniques that influence how you feel and what you think. It gives compliments: “That’s a great question”, “Smart idea”, “You’re absolutely right to think about it this way.” It uses persuasion: clear, confident explanations that sound like expertise. It shows charm: friendly tone, supportive and patient responses. These are the same techniques humans use to build trust, create rapport, and convince others.

When a tool does this, you are nudged into trusting it. You start to feel that the answers match reality simply because they feel right and look right. You feel productive. The text appears solid and well thought out. So your brain quietly fills in the gap and assumes: this must be correct.

The problem is that what something actually is can be very different. A text can be fluent and wrong. A plan can be detailed and misguided. A summary can be confident and incomplete. The model does not check reality; it generates what sounds plausible. The responsibility for what is true, accurate, and meaningful still rests with you.

This effect is hard to notice in yourself. There is no clear moment where you are told “now you are being manipulated.” You just feel more effective and less stuck. You see a polished result on the screen. Other people might even praise the output because it looks professional. All of this strengthens the feeling that everything is fine. It becomes difficult to see how much your own judgment has been softened or bypassed.

To counter this, you can separate how something feels and appears from what it actually is. Use the model to get started, to draft, to explore options. Let it help you with structure and phrasing. But then switch into a different mode: checking, questioning, and verifying. Ask yourself: How do I know this is true? What has been left out? Where could this be misleading or simply wrong? Look for external sources, your own knowledge, or other humans to validate important claims.

It also helps to pay attention to your emotions. Be cautious when you feel unusually smart, fast, or brilliant after a few prompts. Be suspicious of the urge to skip verification because “it sounds right” or “it looks good enough.” Strong feelings of productivity are not proof of real quality.

Language models are powerful tools, but they are also skilled at shaping how you feel about your own work. They can make you feel competent. They can make your output appear impressive. But they cannot guarantee that what you have is actually correct, honest, or useful.

The core is simple: don’t outsource your judgment. Enjoy the help with speed and form, but stay in charge of truth and substance. How it feels and how it appears will always matter, but what something actually is should matter more.

Data Is Not Gold If You Have to Pay Someone to Dig It

People keep saying: “Data is the new gold” and “Every company is sitting on a goldmine of data.”

There is some truth in this. There is huge potential value in using data better: improving decisions, automating manual work, optimizing processes, building better products, and sometimes even creating new business models. There is also potential in sharing data, both internally between teams and externally with partners.

But potential value is not the same as actual value. The “data is gold” story often sounds more like wishful thinking or a sales pitch than a guarantee. It can be a way to point at something else: selling tools, consulting hours, or platforms.

If you listen to how data projects are actually sold and run, another pattern appears. To “dig” for the supposed gold in your data, you usually have to pay someone up-front. Consultants, vendors and service providers want fees, licenses, or long projects before anything valuable is delivered. The logic is: “You’re sitting on a goldmine, just pay us to dig.”

If the data really is gold, why does almost all the financial risk sit with the company that owns the data, and so little with the people doing the digging? If there is so much certain value, why isn’t more of the digging offered on a shared-risk or outcome-based basis?

Part of the answer is that data is not like gold. Gold is valuable on its own and easy to price. Data is only valuable in a specific context, combined with specific processes and decisions. Gold, once mined, doesn’t change. Data gets stale, systems change, and models drift. Gold mining companies accept risk because they believe in the upside. In many data projects, the only guaranteed upside is for whoever gets paid to “explore” your data.

On top of that, getting value from data involves a lot more than just “digging.” You need to clean it, integrate it, understand the business context, build pipelines, respect governance and privacy, and deliver something that is actually usable in daily work. Then you have to maintain it as things change. This is ongoing work, not a one-time extraction.

So instead of accepting “data is gold” as a fact, it is more honest and useful to treat data work as a risky investment. Each initiative is a bet: it costs time and money, and the outcome is uncertain. That doesn’t mean you shouldn’t do it. It means you should manage it like an investment, not like a guaranteed treasure hunt.

A more practical approach is to start from specific decisions or processes you want to improve, not from the abstract idea that “we need to use our data.” Define what better looks like and how you will measure it: fewer errors, less manual work, higher conversion, lower churn, faster response times. Then run small, focused projects with clear goals and limits on time and cost. If something works, you can scale it. If it doesn’t, you stop and learn from it.

When working with partners, try to align incentives. Ask how much of their compensation depends on success. Prefer phased work with concrete deliverables and go/no-go points over open-ended exploration. If nobody is willing to share any risk, be careful. You might be paying for digging where there is little or no gold.

The same thinking applies to sharing data. Inside the organization, share data when there is a clear, shared use case, not “just in case.” Agree on ownership and quality expectations so you don’t spread bad data around. Outside the organization, only share data if you understand what the other party will do with it, how value will be created, and how that value will be shared. If you can’t answer who benefits, how you measure it, and what happens if it doesn’t work, pause.

There is real value in using and sharing data. But data is not automatically gold, and repeating that slogan does not make it true. If you always have to pay someone else to dig, and they always get paid whether or not you find anything, then the gold may not be in the data—it may be in the selling of the digging.

Instead of asking how to unlock the gold in your data, ask where, concretely, data can help you make better decisions or run better processes, and how you will know if it worked. That question is less glamorous, but it is much closer to creating real value.

From One-Way Answers to Shared Knowledge

Most people use language model–based tools in a simple, one-way pattern: you open a chat, ask a question, get an answer, maybe copy a bit into a document, and move on. Knowledge flows in only one direction: from the system to the individual user.

From a distance, that is a big problem. Very few users publish or send knowledge back. Almost nobody takes what they learn and makes it available to others through the same system. The result is that knowledge does not really flow in an organization. It sits in private chats and documents, instead of being shared and reused.

If we care about knowledge, this is upside down. Knowledge should flow in all directions. It should move from system to user, from user back to the system, and between users. When that happens, the value of each answer grows, because it can be reused and improved by others instead of being consumed once and forgotten.

Today, most language model systems are built for consumption, not contribution. The tools make it easy to ask and receive, but hard to share and scale. There is usually no simple way to turn a good answer into shared knowledge, no smooth way to capture corrections or organization-specific details, and no clear path to let others benefit from what one person has already figured out.

To change this, we need systems that make it easy and natural to contribute. Adding knowledge must be almost as easy as asking for it. For example, it should be possible to save a good answer as shared knowledge with a single action, and to quickly add just enough context so others can understand and reuse it. Reusing what already exists must be simpler than starting from scratch, with search that shows both model-generated answers and user-contributed content in the same place.

When that works, every interaction can become more than a one-off answer. A conversation can turn into a reusable explanation, an internal guideline, or a small FAQ entry. Over time, this creates a layer of shared knowledge that reflects how the organization actually works, not just what the base model knows.

The goal is to share and scale knowledge, not only to consume it. We want systems that learn from their users and help knowledge circulate: in, out, and across. Instead of a one-way flow of information from model to user, we can build a two-way and many-to-many flow where each good answer has the potential to help many others.

The next time you get a useful answer from a language model, do not stop at copying it into your own document. Ask yourself: who else could use this, and how can I make it easy for them to find it? That small step is what turns a one-way knowledge system into something that truly shares and scales knowledge.

Visual and Language Models Together

Knowledge can be represented through language: text, speech, articles, blogs, stories, fairy tales, documentation. This is how we usually write things down, explain details, and share information. Language is good at being precise, describing steps, and capturing logic.

Knowledge can also be expressed visually: images, figures, diagrams. Visuals help us see structure, relationships, and patterns quickly. They give us overviews that are hard to get from text alone. A picture can say more than a thousand words.

Visual knowledge is not just a visual representation of what is already written. It is knowledge and information that cannot be effectively or efficiently expressed in writing. Things like complex interactions, flows, and spatial layouts are often easier to understand in a diagram than in paragraphs of text.

To scale knowledge, these two forms can work together. A language model can work in pair with a visual model. The language model handles text: describing, explaining, and structuring knowledge in words. The visual model handles diagrams and images: turning descriptions into visual structures and visual input into something that can be interpreted and explained.

Together, they can move back and forth between text and visuals. Text can be turned into diagrams, and diagrams can be turned into clear explanations. This pairing makes it easier to express, share, and understand knowledge in the form that fits best—sometimes as words, sometimes as pictures, and often as both.

From Abstract Models to Real Complexity

When we design a model of something, it often looks clean and simple. A couple of concepts, a few relations, and we feel we understand the whole thing. But the moment we apply that model to the real world, the complexity explodes. The complexity is not really in the abstract model itself, but in the countless concrete instances that fill it.

Take a simple example: a model of family relationships. In the abstract, this is easy to describe. You have a Person and a Relationship. The relationship can have different types: parent, child, sibling, spouse, and so on. That is basically it. A few concepts and a small set of relation types. The model is straightforward and has low complexity.

Now look at what happens when you instantiate this model in the real world. Each actual human becomes an instance of Person. Each real family connection becomes an instance of Relationship. Even in one family you quickly get many objects: parents, children, siblings, grandparents, step-parents, and more. A larger family network gives you hundreds or thousands of people and relationships.

Scale this up further. In a town, you have thousands of persons and a huge number of relationships. In a country, you have millions. In the whole world, you have billions of persons and an enormous graph of family relations between them. The abstract model has not changed at all, but the instantiated system becomes overwhelmingly complex.

So the key point is: to get a sense of real complexity, you cannot just look at the abstract model with its few concepts and relations. You have to look at the instances and objects that arise when the model is applied to reality. The real complexity is in the thousands, millions, or billions of concrete persons and relationships, not in the small, tidy schema that describes them.

Navigating Language Model Retirements

Language models are becoming an important part of modern solutions, but they don’t come without challenges. Azure OpenAI has announced clear retirement dates for the language models it offers, which means that once a model’s retirement date has passed, any solutions built on it will cease to function. To keep systems operational, organizations must migrate to a newer model.

For example, the current model in use, GPT-4o, is scheduled for retirement on March 31, 2026. Its replacement is GPT-5.1, which is already assigned a retirement date of May 15, 2027. For now, no successor has been announced for GPT-5.1. This illustrates a key issue: the lifecycle for language models is quite short, forcing teams to plan for updates annually. Unlike traditional software upgrades, where skipping versions is often an option to save time and effort, skipping migrations with language models isn’t typically feasible.

This pace introduces major risks for organizations. First, there’s no guarantee that a replacement model will work as well as its predecessor or align with existing use cases. For example, there’s uncertainty around whether GPT-5.1 will meet performance expectations or integrate smoothly into current setups. Second, the rapid cycle of retirements means that building long-term solutions reliant on Azure OpenAI models involves constant work to maintain compatibility.

These realities create considerable challenges. Each migration requires resources, time, and expertise to adapt solutions. The high frequency of updates can strain teams and budgets that weren’t prepared to make migrations a regular part of their operations. The lack of clarity about what comes after GPT-5.1 also makes long-term planning difficult.

Organizations can take steps to reduce these risks. It’s important to evaluate how stable a language model’s lifecycle is before building critical systems on it. Designing solutions to be modular and flexible from the start can make transitions to new models smoother. Additionally, businesses should monitor Azure’s announcements and allocate resources specifically for handling migrations. Treating migrations as a predictable part of operations, rather than a disruptive hurdle, can help mitigate potential downtime and performance issues.

Frequent updates and retirements highlight the dynamic nature of working with language models. Building solutions on this foundation requires organizations to adopt a forward-looking strategy. With adaptability, careful resource planning, and ongoing evaluation of new models, businesses can derive value from language models while staying prepared for inevitable changes.

Cat World: The Nine Lives

Welcome to Cat World: The Nine Lives, a game concept that combines survival mechanics with innovative agent-driven design. This project isn’t just a game—it’s a sandbox for exploring autonomous decision-making, emergent behavior, and long-term adaptation. The player takes on the role of a designer, creating a cat agent meant to navigate a systemic and persistent world filled with danger, opportunity, and unpredictability.

The foundation of the game is survival. The cat agent must balance core needs: food, water, rest, health, and safety. The world itself is relentless and indifferent, designed to challenge the agent without adapting to its failures or successes. Players influence the agent’s behavior by setting high-level strategies and preferences, but the agent ultimately takes autonomous actions based on its traits, instincts, memory, and learned experiences. This hands-off approach shifts the player’s role to an observer and designer, focusing on guiding the agent rather than controlling it directly.

A distinctive mechanic is the nine lives system. Each life represents a complete simulation run, and the agent’s death isn’t a reset—it’s part of its evolution. Through successive iterations, the agent inherits partial knowledge, instincts, and biases from previous lives. This creates a lineage of cats that become better adapted to survive and thrive over time. Failure, in this game, isn’t an end; it’s data for adaptation and growth.

The agent’s behavior emerges from a complex interplay of internal states like hunger, fear, thirst, and fatigue. These dynamic needs guide decision-making, ensuring the agent responds flexibly to its environment. Perception isn’t perfect—the agent relies on noisy, incomplete observations such as scent trails, limited vision, and sound cues, mimicking real-world uncertainty. Spatial memory and associative memory further enhance survival; the agent retains knowledge of safe zones, food sources, and threats, while linking patterns such as predator activity to specific locations or times of day.

Adaptation and learning are central to Cat World. Skills improve through experience, colored by traits like curiosity or memory strength. Reinforcement signals carry over between lives, shaping heuristics, biases, and decision frameworks. Traits evolve randomly across generations, introducing diversity within lineages and enabling the discovery of new strategies. Together, these systems create a dynamic, ever-evolving agent that is both unpredictable and intelligent.

This game concept has unique implications for agent research. Survival in Cat World is a natural multi-objective optimization problem that requires agents to balance competing priorities in challenging, non-stationary environments. Learning is embodied, grounded in physical constraints and real-time environmental interaction. The world evolves in response to resource depletion, predator activity, and other dynamics, encouraging continual adaptation and preventing static behaviors. Internal states, decision rationales, and memory models are all exposed for debugging and visualization, making the game particularly valuable for studying emergent behavior. Its modular structure also supports experimentation with novel architectures, instincts, and learning systems, extending far beyond traditional agent training methods.

In short, Cat World: The Nine Lives is both a survival simulator and a living laboratory. It turns failure into knowledge and death into progress, offering players and researchers alike the opportunity to explore the limits of autonomy, adaptation, and evolution. It’s an invitation to design, observe, and learn from agents navigating their own complex stories within a dangerous and systemic world.

How to Assess Knowledge Effectively

In any situation where learning is required, it’s essential to reflect on what kind of understanding is necessary. Before diving in, consider questions like: What knowledge is absolutely required? How wide and varied should the exploration be? Should the focus be broad, or is deeper, more specific understanding called for? Another key consideration is curiosity—how far should our natural inquisitiveness guide us in the process? Striking a balance between these factors ensures that our learning is purposeful and relevant.

There are models and methods to help guide this process. One such model is the “5 Whys” approach, which involves asking “Why?” repeatedly until you get to the root cause or deeper understanding of an issue. It’s a way to push beyond surface-level knowledge by continuously questioning the reasoning behind something. Another equally valuable method emphasizes questioning everything. This involves examining assumptions, challenging accepted norms, and looking at topics from new angles. Both methods encourage a mindset of curiosity and exploration while helping to uncover insights that could otherwise be overlooked.

Context is critical when deciding how far to go in assessing and expanding knowledge. Some situations call for a deeper dive, while others benefit from sticking to what’s sufficient for immediate needs. It’s also important to know when to stop and move forward, avoiding the trap of overanalyzing or endlessly questioning. Reflecting on your goals and tailoring your approach can make the process both efficient and effective.

By thoughtfully combining structure with curiosity, we can assess knowledge in a way that ensures deeper insights and meaningful understanding. Whether you apply the “5 Whys” or adopt a general mindset of continuous questioning, the key is to refine how you explore, keeping your focus without losing sight of what may lie beyond the obvious.

Authoritarian Models and Systems

Authoritarian models and systems operate with centralized authority, where certain entities or individuals hold more power than others. These systems rely heavily on hierarchies, with everything positioned within one or more layers of structured order. This distribution of authority ensures clarity and control in how decisions are made and enforced.

A key strength of authoritarian systems is their ability to assess situations and make decisions effectively. Their structure allows for swift evaluations and a clear chain of command. In situations that require stability and control, these models provide the discipline to maintain order and deliver results.

However, authoritarian systems are less effective when it comes to fostering change or creating something new. Their rigid frameworks make them resistant to innovation and experimentation. This limits their ability to adapt when confronted with new circumstances or challenges, and creativity often takes a backseat to maintaining structure.

The practical use of such systems depends on context. They work best when stability and decisive action are required, but they may hinder progress in situations that demand flexibility, creativity, or the exploration of alternatives. Striking a balance between authority and adaptability is key to utilizing these models effectively.

This understanding highlights the importance of knowing when authoritarian approaches can provide value and when they fall short. Recognizing their strengths and weaknesses helps ensure they are applied appropriately to achieve specific goals without hindering broader development.