Benjamin LaGrone

Author: benlagrone

  • Why AI Workers Need Guardrails

    A giant sextant-shaped signal switchyard routes cyan rails across a dark digital grid, with one orange verification gate holding a route.

    AI workers are easy to misunderstand.

    Give a model a ticket, a repository, and a terminal, and it can produce a remarkable amount of visible activity: commands run, files change, tests pass, pull requests appear. That activity can look like progress. Sometimes it is. But it is not, by itself, a reliable definition of delivery.

    Sextant began as an attempt to take that distinction seriously. The goal was not to create an autonomous factory that turns every request into code. It was to build a control plane for AI-assisted work: one that can break a desired outcome into bounded tasks, route work deliberately, preserve evidence, and distinguish a worker finishing from a result actually being ready to trust.

    The project has been most valuable where it has failed. Those failures have made the operating model more concrete.

    Why it is called Sextant

    Sextant is the orchestrator around the workers. It measures and estimates work, breaks it into bounded tasks, schedules and routes those tasks deliberately, and optimizes how work moves through the system. It also retains the evidence needed to judge the result. It is not the name for the workers themselves.

    The name comes from the navigational instrument. A sextant does not steer a ship or choose its destination. It helps a navigator establish position by taking a measurement against known reference points. That is the role I want this system to play in AI-assisted delivery: measure the work, estimate its shape and effort, coordinate its movement, and make the state of work legible. It should show what was requested, what a worker actually did, what evidence exists, and what still requires a decision or verification.

    The metaphor is intentionally modest. Sextant is meant to provide orientation and discipline around automation, not to pretend that an automated system can replace judgment.

    The original idea: workers need a system around them

    The attractive story about agents is simple: describe the goal, dispatch several workers, and collect the result. The harder reality is that software delivery is full of dependencies, hidden assumptions, ownership boundaries, and quality gates.

    A useful worker therefore needs more than a prompt. It needs a clear unit of work, an explicit definition of done, the right repository and branch context, limited authority, and a way for another system—or another person—to inspect what happened.

    That is the role Sextant is meant to play. It treats work as a sequence of progressively smaller, reviewable units: an outcome can be decomposed into stories, then atomic tasks. Each task should have a concrete scope, acceptance criteria, and a record of the evidence expected at the end.

    The point is not bureaucratic ceremony. It is to make it possible to answer a basic question honestly: what do we know happened, and what still needs to be checked?

    The first hard lesson: finished is not successful

    One early mistake was allowing the end of a worker run to carry too much meaning. A process can exit. A worker can report completion. A test command can return green. None of those facts alone establishes that the requested outcome was achieved.

    This is especially important with AI-generated work because a plausible-looking implementation can be incomplete in ways that are not obvious from the last message. It may satisfy a narrow test while missing a requirement. It may change the right file in the wrong checkout. It may make a local improvement without proving that the intended workflow still works end to end.

    The correction is an explicit state model. A worker can finish its assigned execution and enter a reviewable state. Verification is a separate step. Only evidence that matches the intended task, revision, and acceptance criteria should allow work to be called successful.

    That may sound obvious, but it changes behavior. It prevents a dashboard from treating a completed run as a completed product decision.

    What failed in practice

    The system has encountered more ordinary failures than dramatic ones, which is exactly why they matter.

    Some tasks were not sized well enough. A worker cannot recover clarity from a request that bundles architecture, implementation, tests, deployment, and business judgment into one opaque instruction. The result is often either shallow work or an unhelpful attempt to solve the wrong problem.

    Queue and execution reliability also matter. A task marked ready is not useful if the pickup loop does not reliably turn that state into a visible, attributable run. A model endpoint being healthy does not prove that the worker has the repository access, credentials, or tool path required for the task.

    Review evidence created another class of failure. A reviewer can produce malformed output, evaluate the wrong revision, or hit a tool limit. A positive-sounding summary is not enough if the underlying checks and findings cannot be inspected. Similarly, a passing local test suite is useful evidence, but it is not a substitute for validating the behavior that the user actually needs.

    Finally, shared workspaces create their own risk. When multiple workers touch a repository, an apparently correct change can be contaminated by unrelated local edits or collide with another worker’s assumptions. Isolation is not a convenience feature; it is part of the reliability model.

    The controls that are improving it

    The improvements have been less about making workers seem more autonomous and more about making their boundaries clearer.

    Smaller, explicit tasks. Work is decomposed until a worker has a bounded objective, known inputs, and acceptance criteria that can be checked. If a task remains too broad, it should be sized or clarified before implementation—not disguised as a single “do everything” prompt.

    Isolated execution. Per-job checkouts reduce the chance that one worker silently relies on, overwrites, or is confused by another worker’s local changes. The resulting evidence can be tied to a specific task and revision.

    Decision receipts and evidence. A worker should leave more than prose. The system needs a record of the selected task, the relevant revision, commands or checks performed, outputs, and the relationship between those outputs and the acceptance criteria.

    Independent verification. Verification is deliberately distinct from execution. It checks the actual artifact and intended behavior rather than accepting a worker’s self-report. This is where tests, review, and human judgment each have different roles.

    Bounded recovery. Some failures are transient or mechanical: malformed review evidence, a constrained tool session, an interrupted run. A limited retry can be sensible when it is targeted and preserves the original evidence. Unlimited retries are not resilience; they are a way to hide a system that is not learning from its failures.

    Honest states. “Queued,” “running,” “worker finished,” “needs verification,” “verified,” and “blocked” should mean different things. Clear states make it easier to see whether the next action is to wait, repair infrastructure, clarify scope, review an artifact, or involve a human decision-maker.

    The human role did not disappear

    The more I work with AI workers, the less interested I am in the fantasy of removing people from the loop. The valuable human work moves upstream and downstream.

    Upstream, someone has to decide what is worth doing, what the constraints are, and what success means. Downstream, someone must decide whether the evidence is sufficient, whether the result fits the larger system, and whether to accept the tradeoffs. Workers can accelerate execution and surface information, but they do not eliminate accountability.

    That is why I think the right comparison is not “AI worker versus engineer.” It is closer to a new form of instrumented delivery system. The workers are components. The task boundaries, evidence model, verification gates, and human decisions are what make the components safe to use.

    What I am watching next

    The interesting questions now are operational. Can the system size work accurately enough to avoid both over-fragmenting it and handing a worker an impossible bundle? Can it preserve provenance as tasks move between planning, execution, review, and release? Can it report uncertainty clearly enough that a human knows where attention is needed?

    I do not think reliable AI-assisted delivery will come from a single breakthrough prompt. It will come from disciplined systems that make the limits of each worker visible, retain the evidence of what occurred, and refuse to confuse motion with progress.

    That is the lesson Sextant keeps teaching me: the purpose of a worker is not to look busy. It is to make a trustworthy contribution to a result that can be verified.

    If you are building with agents, I would be interested in the controls that have made your own workflow more reliable—and in the failure modes you discovered only after the first impressive demo.

  • An Initial Note on the General Emergence Model

    Complex systems rarely move through the world as if every future were equally available.

    An abstract Grid landscape where a realized amber path crosses a hinge and reshapes the terrain of future possibilities.

    A company cannot make every strategic choice at once. A city cannot redesign itself without regard to streets, institutions, and yesterday’s decisions. A biological system does not develop from a blank slate. In each case, the present opens some paths, closes others, and makes a few more likely than the rest.

    That simple observation is the starting point for what I am calling the General Emergence Model. This is an early research framework, not a finished scientific theory. Its purpose is to give me a clearer, domain-neutral way to think about how novelty, adaptation, and path dependence arise in systems over time.

    A note on process: I used AI to help write and edit this post as a way to share ideas I am actively exploring. The framework remains a work in progress, and I am responsible for its claims, examples, and errors.

    Possibility is constrained

    At any moment, a system has a range of possible next states. But possibility is not the same as imagination. The reachable next states are shaped by the system’s current configuration, its governing rules, its constraints, its environment, and its history.

    History matters because systems carry consequences forward. A decision can create a capability, a dependency, a bottleneck, or a habit. Those changes influence what can happen next. A transition is therefore not simply movement from one state to another; it can alter the landscape of future transitions.

    This is the core intuition: emergence is not only about what appears. It is also about how the space of what can appear changes as a system moves through it.

    A concrete example

    An abstract possibility map showing a path through constraints and history toward a newly constructed future.

    Consider a growing city. Its next decisions are constrained by existing streets, land use, utilities, tax base, institutions, and the expectations of residents and businesses. Building a transit line is one possible transition. If it happens, it changes more than travel times: it can change where development is viable, which investments make sense, and which later choices become politically or financially realistic.

    The city has not merely arrived at a new state. It has changed some of the conditions that shape its next possibility space.

    The same pattern may be useful in very different settings: an organization learning a new capability, a software platform accumulating technical decisions, an ecosystem responding to disturbance, or a person forming habits. Those examples should be treated as tests of the framework, not as definitions of it.

    What I am trying to model

    The General Emergence Model treats a system as moving through constrained possibilities over time. A transition becomes real, produces a new state, and may change the rules, constraints, environment, or relevant history that determine what is reachable afterward.

    That framing deliberately resists a single-cause explanation. It does not assume that every important change comes from an internal property, an external shock, an optimization process, or a hidden master plan. Instead, it asks a more practical question: given what this system is now, what can it plausibly become next—and how would each realization reshape the answer?

    I am especially interested in whether this approach can make path dependence easier to describe without making it mysterious. Some outcomes feel inevitable only after they occur. Beforehand, they were among a constrained set of possibilities, each carrying different implications for the futures that followed.

    What this is not

    This is not a claim that one model can explain every complex system. It is not a substitute for domain knowledge, measurement, or evidence. And it is not yet a validated predictive engine.

    The work ahead is to make the concepts precise enough to test: define the parts of the model clearly, apply them to bounded examples, identify where they fail, and learn whether they provide useful explanatory or predictive value beyond a compelling metaphor.

    For now, I am sharing it as an opening research note. If you work with a system where decisions reshape the future options available to that system, I would be interested in the cases you think could challenge—or sharpen—this idea.

  • Alchemy and the Feeling of Lost Knowledge

    One thing that becomes interesting when reading about alchemy is that the people practicing it did not think they were doing something primitive.

    To them, it was science.

    More specifically, it was the attempt to rediscover a science they believed had once existed but had been lost.

    Many of the texts from the medieval and early Renaissance periods carry that assumption. Wisdom was believed to have existed in earlier ages — associated with figures like Solomon or Hermes — and later generations were working from fragments. Symbols, procedures, planetary calendars, and strange diagrams were attempts to reconstruct something whose original logic had disappeared.

    In that sense, alchemists were not always trying to invent something new.

    They believed they were recovering something old.

    Whether that belief was correct is another question. But the intellectual posture is interesting. It assumes that knowledge can be lost, scattered, and partially recovered through study.

    Reading those texts today produces a strange feeling because the mindset is not entirely foreign.

    Working with artificial intelligence sometimes produces a similar impression.

    AI research is often described as creating intelligence, but that is not quite right. Most of the time we are discovering patterns that allow certain behaviors to emerge. We are shaping systems that produce language, reasoning, or prediction, but we are not creating life.

    In that sense the technology can feel uncanny.

    Not because it is mystical, but because it resembles something older: imitation rather than creation.

    If medieval thinkers described alchemy as trying to recover hidden processes in nature, modern AI sometimes feels like a different kind of experiment.

    We are not animating life.

    But we are building systems that can imitate parts of it.

    At times it feels less like creation and more like a kind of intellectual necromancy — raising echoes of intelligence rather than generating a living mind.

    That metaphor may be imperfect, but it captures something about the experience of working with these systems.

    They behave enough like thinking that we recognize the pattern.

    But not enough to believe we have actually created life.

    And that tension — between imitation and reality — is probably going to define the next era of technology.

  • Alchemy, Lost Knowledge, and the Strange Feeling Around AI

    When people talk about alchemy today, they usually imagine something primitive — a strange mixture of superstition and failed chemistry.

    But for the people practicing it, alchemy was not superstition.

    It was science.

    More precisely, it was the attempt to recover a science that they believed had once existed but had been lost.

    Many medieval and early Renaissance thinkers believed that earlier civilizations possessed deeper knowledge about the structure of nature. Solomon, Hermes, and other ancient figures were often treated not merely as legendary characters but as custodians of wisdom that later generations only partially understood.

    Alchemy, in that sense, was not always seen as inventing something new.

    It was often framed as rediscovering something old.

    That perspective changes how the tradition looks. Instead of imagining alchemists as naive experimenters chasing impossible transformations, you start to see them as scholars searching through fragments of a broken intellectual inheritance.

    Grimoires, symbolic diagrams, planetary calendars, and ritual procedures were all part of that search. They were attempts to reconstruct a system whose full logic was no longer visible.

    Whether that reconstruction succeeded is another question.

    But the attitude behind it is surprisingly familiar.

    In some ways, the modern conversation around artificial intelligence carries a similar atmosphere.

    AI research is often described as creating intelligence, but that description can feel misleading. What we are actually doing most of the time is discovering structures that allow certain kinds of behavior to emerge.

    We aren’t creating life.

    We are coaxing patterns out of systems that already exist.

    When a model suddenly produces language that feels coherent or insightful, the reaction is often strangely similar to the reactions described in older texts about hidden knowledge. It feels less like building a machine and more like uncovering something that was already latent.

    That sensation is part of why the technology feels uncanny.

    Not because it is supernatural, but because it touches an old human instinct: the sense that intelligence and life are mysteries we can approach but not fully manufacture.

    In that sense, AI sometimes feels less like creation and more like imitation.

    Or perhaps something closer to an ancient metaphor.

    Not the creation of life.

    But the attempt to call something back into motion.

  • Why Alchemy Becomes Interesting

    For most of my life I thought of alchemy as a strange footnote in history — an odd mixture of superstition, early chemistry, and medieval imagination.

    Gold, potions, philosophers’ stones.

    The usual story is that alchemy was eventually replaced by real science, and that was the end of it.

    But the more time I spend reading older texts, the more interesting it becomes. Not because the claims are literally true in a chemical sense, but because of the intellectual world that produced them.

    Alchemy did not appear out of nowhere.

    It grew in a culture shaped by several overlapping traditions: biblical wisdom literature, classical philosophy, early natural science, and the ritual practices recorded in various grimoires and manuals of knowledge.

    When you begin to trace those influences, something interesting emerges.

    Many of these traditions assume that the universe is not random, but ordered — and that order can be studied.

    In the biblical tradition this appears most clearly in the wisdom literature. Proverbs, Ecclesiastes, and later interpretations associated with Solomon all assume that reality operates according to patterns. Wisdom is the ability to recognize those patterns and live in harmony with them.

    In later centuries that idea expanded into more elaborate systems.

    Scholars and monks studied calendars, planetary movements, and liturgical cycles. Time itself was treated as structured. The calendar was not just a schedule but a reflection of cosmic order. Medieval clocks and astronomical devices were built partly as tools for understanding that order.

    Grimoires — which today are often treated as occult curiosities — were originally something closer to manuals of structured practice. They recorded procedures, correspondences, and timings. In many cases they were attempts to formalize how human action might align with the perceived order of the world.

    Alchemy sits in the middle of all of this.

    It was not simply about turning lead into gold. That goal was often symbolic of something larger: the belief that nature itself follows processes of transformation. If the structure of nature could be understood, then those processes might be guided or accelerated.

    Modern science eventually replaced the symbolic language of alchemy with chemistry and physics. But historically, alchemy represented an early attempt to unify several ideas:

    that the world is ordered,

    that transformation follows patterns,

    and that careful study might reveal those patterns.

    Whether those assumptions were correct in every case is another question.

    But the intellectual ambition behind them is worth understanding.

    Because in some ways, the same impulse still drives modern research — including the development of artificial intelligence.

    We are still trying to discover the structure behind complex systems.

    We are still looking for the patterns that explain how transformation happens.

    And in that sense, the distance between medieval alchemy and modern technology may be smaller than it first appears.

  • Reading Wisdom Literature Like a Systems Engineer

    Engineers tend to think in systems.

    Inputs, outputs, feedback loops, constraints.

    When something fails, the instinct is to ask how the system is structured rather than blaming one individual component.

    Lately I’ve noticed that many ancient wisdom texts can be read in a similar way.

    Take Proverbs. It’s often treated purely as moral instruction, but another way to read it is as a long observation about how human systems behave.

    Certain patterns consistently lead to stability.

    Others lead to chaos.

    Discipline, patience, and restraint tend to produce long-term order. Impulsiveness and pride tend to produce the opposite.

    That sounds less like abstract morality and more like an early attempt to describe how human systems behave over time.

    Modern systems theory uses different language — feedback loops, incentives, emergent behavior — but the underlying observation feels similar.

    The vocabulary changed.

    The pattern recognition didn’t.

  • AI Is Making Philosophy Practical Again

    One thing I didn’t expect when working in AI is how quickly the conversation becomes philosophical.

    At first glance the field looks purely technical: models, infrastructure, GPUs, training pipelines.

    But once systems start producing coherent language or solving problems, the deeper questions show up immediately.

    What exactly is intelligence?

    For centuries philosophers debated that question without any real way to test their ideas. Now we’re building systems that display pieces of what we call intelligence, and suddenly the debate feels very practical.

    Watching an AI system generate something useful forces you to ask a strange question:

    How much of intelligence is understanding, and how much is pattern recognition?

    That question goes back a long way. Aristotle wrestled with it. Augustine wrote about the nature of memory and reasoning. Medieval thinkers tried to break it down using logic.

    AI didn’t invent the question.

    It just turned it into an engineering problem.

  • Why I Started This Site

    For most of my career I’ve built systems.

    Data platforms, cloud infrastructure, machine learning pipelines — the kind of things that quietly sit behind organizations and move information around.

    When you spend enough time building systems, you start seeing systems everywhere.

    Not just in technology. In philosophy. In religion. In how people behave. In how organizations succeed or fail.

    Artificial intelligence has made this even more interesting. Working close to AI forces you to think about questions that used to belong mostly to philosophers.

    What is intelligence?

    What does it mean to understand something?

    How much of reasoning is actually structure and pattern?

    At the same time, when you read older texts — especially things like Proverbs, Augustine, or classical philosophy — you start noticing that people were wrestling with many of the same questions long before computers existed.

    This site is mostly a place for working through those ideas.

    Some posts will be about AI and technology.

    Some will be about philosophy or religion.

    Some will just be attempts to connect things that normally get discussed in completely different circles.

    I don’t have a grand thesis here.

    Just curiosity and a place to think out loud.

  • Hello world!

    Welcome to WordPress. This is your first post. Edit or delete it, then start writing!