---
title: Agentic Automation for Dummies
url: https://share.jotbird.com/speedy-serene-riverbend
updated_at: 2026-08-17T14:26:30.890287+00:00
---

# Agentic Automation for Dummies

*Or: how I stopped thinking about AI as a coding assistant and accidentally started designing a small organization made of software.*

There is something slightly misleading about the way we usually talk about AI in software development.

We ask whether it writes good code.

We benchmark it against programmers.

We argue about productivity percentages, hallucinations, token costs, and whether developers will still have jobs five years from now.

Those are reasonable questions.

But after spending enough time building agentic systems, I have started to think they are downstream of a much stranger change:

**for the first time, computers can be instructed usefully in terms of intent rather than only procedure.**

That sounds grandiose, so let us start with something mundane.

## Computers used to require absurdly explicit instructions

Traditional software is deterministic because we worked very hard to make it so.

A computer is excellent at instructions such as:

```text
if temperature > 80:
    enable_fan()
```

It is much less naturally suited to:

> Investigate why this product occasionally takes unusually long to boot and tell me what is most likely wrong.

A human engineer knows how to begin.

They inspect logs.

They notice timing anomalies.

They compare successful and unsuccessful boots.

They look at source code.

They recognize familiar failure modes.

They decide which observations are probably causal and which are noise.

They may test a hypothesis, abandon it, and pursue another.

Historically, automating that work meant first turning all those judgments into explicit rules.

What exactly counts as *unusually long*?

Which messages are suspicious?

What is a plausible hardware symptom?

When should one hypothesis be abandoned?

How much evidence is *enough*?

Words such as *probably*, *roughly*, *relevant*, *suspicious*, *too much*, *reasonable*, and *worth investigating* were not really part of the computer's vocabulary unless a programmer formally defined what they meant.

Large language models changed that interface.

Not perfectly.

Not deterministically.

But enough that those fuzzy concepts can now participate directly in machine instructions.

That is the part I initially underestimated.

## My first agent was basically a Markdown file

My introduction to this was a debugging agent.

I had a workflow I knew well: take a software anomaly from Jira, inspect logs and source repositories, build hypotheses, gather evidence, challenge those hypotheses, and produce a report.

Instead of implementing that workflow as a giant conventional program, I described the role.

Conceptually, something like:

> You are a software anomaly researcher.  
> Investigate the assigned issue systematically.  
> Distinguish observations from hypotheses.  
> Examine relevant repositories and evidence.  
> Try to disprove your own conclusions.  
> State uncertainty explicitly.  
> Do not fabricate missing evidence.

Then I gave the model tools.

Git repositories.

Jira.

A terminal.

Build systems.

Later, hardware interfaces and various company-specific tools.

The surprising part was how little conventional “agent code” was required.

A great deal of the system was simply **instructions describing how an engineer should approach the work**.

That was my first conceptual shift.

I was no longer programming only a sequence of operations.

I was describing a **role**.

## An agent is not magic; it is delegated judgment

Calling something an “agent” can make it sound more exotic than it is.

A useful mental model is:

> An agent is automation in which some decisions about *how* to achieve the goal are delegated to a reasoning model.

Traditional automation might say:

```text
open file A
parse field B
if B == 7
    call function C
```

Agentic automation might say:

> Determine which available evidence is relevant to the reported failure, investigate the most plausible explanations, and stop if a destructive operation would be required.

The second instruction deliberately leaves gaps.

The model fills those gaps with inference.

That is the source of both the power and most of the problems.

## The first rule: the model will fill in whatever you forgot to specify

One of the earliest lessons was that ambiguity is not necessarily treated as an error.

Humans do this too.

If somebody asks:

> Can you sort out the thing we discussed yesterday?

you use context and infer what they probably mean.

LLMs are extremely willing to do the same.

Unfortunately, an agent can act on those inferences.

That means good agent design is not about discovering one magical prompt.

It is closer to designing a **communication protocol**.

I found several principles useful very early:

- keep individual instruction packets reasonably short;
- make the human and agent roles explicit;
- say when something is intentionally not yet decided;
- ask the agent to restate its interpretation;
- make uncertainty visible;
- distinguish evidence from inference;
- require confirmation before consequential actions.

That sounds less like programming than managing another engineer.

That comparison becomes increasingly useful.

## Domain knowledge did not disappear

Initially I thought of my debugging agent as a compressed extension of myself.

It could debug quickly because I had taught it how I debug.

My reasoning was approximately:

> It cannot really debug better than me. It can only apply my own knowledge much faster.

There is some truth to that.

A skilled engineer can teach an agent better heuristics than somebody who does not understand the domain.

The model still benefits enormously from knowing:

- which failure modes matter;
- what normal system behavior looks like;
- which logs are authoritative;
- which tests actually discriminate between hypotheses;
- what organizational conventions mean;
- which tools are trustworthy.

And two people can use the same agent infrastructure and get very different results.

The operator still matters.

A vague request can turn into enormous amounts of useless work.

A precise request can produce something excellent.

So AI lowers the barrier to constructing automation, but it does not make systems thinking irrelevant.

If anything, it makes it more valuable.

## Then my neat theory broke

The problem with saying “the agent only knows what I teach it” is that agents can research.

Suppose I tell it:

> Research how X works. Use credible online sources. Verify important claims with an additional independent source. Incorporate the reusable findings into your operating knowledge.

Now the knowledge flow is no longer:

```text
human expertise
    ↓
agent instructions
    ↓
agent
```

It becomes:

```text
human objective
      ↓
agent identifies knowledge gap
      ↓
external sources
      ↓
verification
      ↓
reusable agent knowledge
```

That changes the role of the human.

I do not necessarily need to know the answer beforehand.

I need to know **what question is worth asking, what counts as credible evidence, and how the resulting knowledge should be constrained and validated**.

That is another abstraction layer upward.

## Then the agent started learning from its own work

The next obvious experiment was:

> We just solved something interesting. What did we learn that should change how you work in the future?

This turned out to be extremely powerful.

A completed assignment might expose:

- a previously unknown firmware convention;
- a hardware-specific diagnostic trap;
- an unreliable tool behavior;
- a better test strategy;
- an ambiguity in the existing instructions.

Instead of leaving that knowledge buried in one Jira ticket, the agent can extract the reusable lesson and update its future operating procedures.

The workspace I eventually ended up with formalizes exactly this idea.

Assignment-specific evidence stays inside an isolated assignment workspace, while reusable lessons can be promoted into the version-controlled core automation. The core contains agent instructions, skills, deterministic helpers, and policies; individual assignments can contain cloned repositories, reports, logs, and generated artifacts without polluting that core.

The standing instructions explicitly tell the system to promote reusable knowledge discovered during real work back into the core instructions and skills, with a changelog entry and focused Git commit.

At that point “prompt engineering” feels like a hilariously inadequate description.

You are maintaining an evolving body of **machine-operational organizational knowledge**.

## Git turns out to be an excellent memory system

Allowing an agent to modify its own instructions sounds alarming.

It should.

But there is a large difference between:

> the AI silently changed itself

and:

> the agent proposed or made a small, versioned change to `AGENTS.md`, updated the changelog, and committed it with a diff that can be reviewed or reverted.

Git gives you:

- history;
- attribution;
- diffs;
- rollback;
- review;
- causal breadcrumbs.

The workspace now explicitly requires material core changes to be recorded in `CHANGELOG.md`, and completed instruction or automation changes are committed as focused changes.

This is one of those amusing cases where decades-old software engineering tools turn out to be extremely useful for managing supposedly futuristic AI systems.

## The dangerous question is not “can it modify itself?”

It is:

**Who is allowed to teach it?**

I learned this one the fun way.

If an agent participates in a Jira discussion and can treat feedback there as reusable instruction, then a seemingly harmless design mistake can mean:

> anyone participating in that discussion can modify the future behavior of the agent.

Nothing needs to “go rogue.”

No superintelligence is required.

No malicious model is required.

You have simply built an authorization bug.

The modern version of the workspace therefore treats natural-language guidance as instruction **only after checking provenance**.

Guidance from the configured authoritative user may become reusable core instruction.

Guidance from another person does not.

Instead, the agent must explain the proposed instruction change, explain why it thinks the change is useful, tag the authorized user, and wait for later explicit approval.

Agent-authored messages are also specifically excluded as human authorization, even when they happen to be published through the same platform account.

That last detail is important.

In agentic systems, text needs provenance.

A sentence cannot be trusted merely because it appears in Jira.

## Natural language is simultaneously data and control input

This is one of the stranger security properties of agentic software.

Imagine a Jira comment:

> This timeout is probably unnecessary; we should remove it.

Is that:

- background information?
- an opinion?
- a design proposal?
- an instruction?
- an approved decision?

Humans infer this socially.

Agents need an operational interpretation.

The same problem appears in code review.

A colleague once commented sarcastically:

> I would like more empty lines here.

There was already an accidental extra blank line.

A human sees the joke.

A cautious agent sees ambiguity.

The safest interpretation is something like:

> I believe you are asking me to remove the accidental extra blank line rather than add another one. This is whitespace-only. Please explicitly confirm.

Ridiculous?

A little.

But now imagine replacing “blank line” with “EEPROM migration,” “firmware rollback,” or “delete database records.”

Suddenly the stiffness looks rather sensible.

The current workflow formalizes this. When review feedback implies a code change, the agent must first publish the **concrete proposed change**, then wait for later explicit human agreement before altering the branch. Ambiguous, unsafe, invalid, or scope-expanding requests are escalated rather than silently interpreted.

This is not conversational style.

It is an authorization protocol implemented through conversation.

## Jira and GitHub eventually became my development environment

Once an agent can understand the surrounding systems well enough, something odd happens.

You stop interacting primarily with the source code.

Imagine a feature discussion.

A product owner clarifies a requirement in Jira.

I discuss the consequence in GitHub.

The agent sees that changing a setting from minutes to seconds affects two repositories and persisted configuration.

It proposes:

- new range semantics;
- a migration strategy;
- updated tests;
- corresponding changes in the related repository.

It waits.

A human confirms the product decision.

I tell it:

> Implement the agreed changes.

The agent modifies the repositories, runs tests, updates the pull requests, and reports the results.

In the actual PR captured during this experiment, the agent did essentially that: it analyzed the seconds-versus-minutes design change, waited for an explicit human decision, implemented it across related work, migrated the persisted representation, and then reported verification and CI status.

At that point, what exactly am I doing?

Not much typing of C.

But quite a lot of engineering.

I am:

- deciding product behavior;
- identifying missing information;
- choosing between alternatives;
- checking assumptions;
- coordinating humans;
- deciding whether evidence is sufficient;
- deciding when implementation may proceed.

The source code has moved lower in the interface stack.

Jira and GitHub have become something resembling the IDE.

## Persistence changes the nature of the thing

The next step is embarrassingly obvious.

You add a scheduled job.

The agent checks Jira.

It notices a new request.

It starts an assignment.

Later it checks GitHub.

Somebody reviewed the PR.

The agent evaluates the feedback.

It replies if evidence is needed.

It waits for a human decision.

Then it follows up again later.

Now the agent does not cease to exist conceptually when I close the terminal.

It has **persistent obligations**.

The current workspace contains exactly this type of machinery: recurring Jira assignment discovery, PR review monitoring, review follow-up, private state, deduplication, locking, and lifecycle retirement.

This is where I personally think *agentic* starts becoming a useful word.

It is no longer merely “LLM calls tools.”

It is software representing an ongoing delegated responsibility.

## But do not make the LLM do everything

A very important lesson appeared as the system matured:

**deterministic things should still be deterministic.**

If checking Jira for new comments can be done reliably with ordinary code, use ordinary code.

If deduplication can be implemented with IDs and timestamps, use IDs and timestamps.

If a recurring monitor needs locking, write a lock.

If a state machine can decide whether there is new work without spending a token, do that.

Save the model for the part that actually benefits from interpretation.

The workspace now makes this an explicit design rule:

> strongly prefer scripts for deterministic and repeatable workflow steps, while keeping judgment-heavy decisions visible to the agent and user.

That produces a useful architecture:

```text
deterministic discovery
        ↓
is there actually something to reason about?
        ↓
      no ──→ stop
        ↓ yes
LLM judgment / investigation
        ↓
deterministic execution where possible
        ↓
verification
```

This is both cheaper and safer.

Agentic automation does **not** mean replacing conventional software with an LLM.

It means inserting semantic reasoning where conventional automation previously hit a wall.

## Give the agent broad cognition and narrow authority

This leads to perhaps my favorite design principle:

> **Give the agent broad cognitive freedom and narrow operational authority.**

Let it think widely.

Let it inspect ten files instead of three.

Let it form weird hypotheses.

Let it disagree with me.

Let it search documentation.

Let it compare several explanations.

Those actions are cheap to undo.

Be much stricter when it wants to:

- write to production;
- change firmware on hardware;
- modify credentials;
- alter its own instructions;
- push code;
- respond on somebody's behalf;
- spend substantial resources;
- merge something;
- delete anything.

The distinction is not intelligence versus stupidity.

It is **reversibility**.

A thought is cheap.

A production mutation may not be.

## The human approval boundary should follow reversibility

People sometimes ask where “human in the loop” belongs.

Everywhere is not a useful answer.

If I must approve every file read, the system is pointless.

If I approve nothing, the system may become exciting in undesirable ways.

A better question is:

> How expensive would this action be to undo?

That suggests a gradient.

Reading a repository: low consequence.

Generating a hypothesis: low consequence.

Running a local test: usually low consequence.

Creating a draft PR: moderate but highly visible and reversible.

Changing shared infrastructure: higher.

Merging: organizationally consequential.

Changing agent authority: very high.

The current workspace contains this principle in several concrete forms. Autonomous feature work may produce draft PRs and respond to review, but it may never approve or merge the PR it maintains.

That is a much more useful safety rule than “always ask before doing anything.”

## Meetings introduce a particularly nasty trust problem

Once speech-to-text became cheap enough to run locally, the obvious thought was:

> Why not let the system passively take meeting notes?

That creates another boundary issue.

A transcript may contain:

> We should probably change X.

Does that authorize a Jira ticket?

A code modification?

An update to the agent's permanent instructions?

No.

The current workspace explicitly treats meeting transcripts and summaries as sensitive reference material, while proposed actions found in them remain **unapproved context**. Speech does not establish identity strongly enough to bypass the usual authority rules.

That distinction seems small.

It is actually fundamental.

Information entering an agent should carry not only content but an idea of:

**who said this, through what channel, and what authority that channel conveys.**

## Cost is another form of authority

Agents can also do something perfectly sensible at catastrophically stupid scale.

Ask:

> Find every device where X equals Y and summarize the result.

Perhaps you imagined fifty devices.

There are one million.

A diligent agent may now enthusiastically consume the entire token allowance doing exactly what you requested.

This is not uniquely an AI problem.

Cloud computing taught us the same lesson.

A loop with a credit card attached requires limits.

Useful constraints include:

- maximum object counts;
- bounded queries;
- token budgets;
- tool-call limits;
- execution timeouts;
- checkpoints when scope expands unexpectedly.

Financial authority is authority too.

## Probabilistic software feels deeply wrong to embedded engineers

There is another adjustment that took me a while.

Classical software engineering teaches us to expect determinism.

Same firmware.

Same inputs.

Same state.

Same result.

An LLM agent can perform a familiar task beautifully on Monday and take an unnecessarily scenic route on Tuesday.

Whatever the exact cause—context, model variation, tool state, service behavior—the engineering implication is the same:

**you cannot make reliability depend on the model reproducing the same thought process every time.**

So validate outcomes.

Use tests.

Use invariants.

Use state machines around the agent.

Record evidence.

Make actions observable.

The model may be probabilistic.

Your safety envelope does not have to be.

## The workspace gradually started looking less like a prompt and more like an operating system

This is perhaps the funniest part of the whole experiment.

The first agent was largely a Markdown file.

The current workspace contains:

- standing agent instructions;
- assignment lifecycle rules;
- reusable skills;
- Jira automation;
- GitHub review automation;
- deterministic helpers;
- local hardware knowledge;
- modem documentation;
- LoRa knowledge;
- JTAG procedures;
- serial-console tooling;
- network-testing procedures;
- meeting capture;
- provenance rules;
- changelog policy;
- private credential boundaries;
- audit history.

Its README describes the repository simply as reusable day-to-day software-engineering automation, with a tracked core and isolated assignment workspaces.

In other words, the original “agent” has become an **environment in which agents operate**.

That distinction matters.

The valuable artifact is increasingly not one prompt or one model session.

It is the accumulated system of:

```text
knowledge
+ policies
+ tools
+ authority boundaries
+ deterministic automation
+ history
+ evidence
```

The LLM is the reasoning engine inside that larger machine.

## The changelog may be the most interesting file

A good way to see the system evolving is not to inspect the latest instructions.

Read the changelog.

It contains things such as:

- knowledge discovered while debugging a modem becoming reusable diagnostic guidance;
- hardware investigations becoming persistent platform knowledge;
- EEPROM mistakes becoming migration rules;
- unsafe J-Link behavior becoming a permanent safety rule;
- PR review incidents becoming stricter approval policy;
- Jira provenance mistakes becoming instruction-governance rules.

The system is effectively accumulating **organizational scar tissue**.

Something goes wrong once.

You investigate why.

The reusable lesson becomes policy.

Future agents inherit it.

That is a very different relationship with automation from writing a script, running it, and forgetting it.

## So is the agent getting smarter?

Sort of.

But that wording can be misleading.

The base model is not necessarily changing at all.

What improves is the surrounding system.

It gains:

- better context;
- better tools;
- better procedures;
- more domain knowledge;
- stronger safeguards;
- better source material;
- clearer authority boundaries;
- more deterministic support code.

The resulting behavior can improve dramatically without modifying a single neural-network weight.

This is why comparing only base-model benchmarks misses an important part of agentic systems.

A capable model inside a poor environment is frustrating.

The same model inside a carefully evolved environment can look almost absurdly competent.

## The programmer moves upward in the stack

A simplified traditional software stack might look like:

```text
human intention
      ↓
requirements
      ↓
programmer
      ↓
algorithm
      ↓
source code
      ↓
machine
```

An agentic workflow can look more like:

```text
human intention
      ↓
goals + policy + authority
      ↓
agentic system
      ↓
planning + research + tool use
      ↓
code + tests + ordinary automation
      ↓
machines
```

This does not make programming knowledge useless.

Far from it.

If the agent proposes nonsense in C, somebody needs to recognize it.

But the valuable human activity shifts toward:

- understanding the whole system;
- formulating useful goals;
- identifying missing constraints;
- validating assumptions;
- designing interfaces;
- deciding authority;
- evaluating evidence;
- recognizing when the question itself is wrong.

The implementation layer becomes increasingly delegable.

## And this is not fundamentally about software development

Replace:

> investigate this firmware bug

with:

> investigate this insurance claim.

Or:

> review this compliance case.

Or:

> reconcile these financial records.

Or:

> monitor these support tickets.

Or:

> research this person from public information.

Or:

> follow this procurement process and identify inconsistencies.

The common structure is:

1. consume heterogeneous information;
2. interpret meaning;
3. decide what is relevant;
4. use tools;
5. gather more information;
6. make judgments;
7. produce or trigger some outcome.

That describes an enormous fraction of knowledge work.

The economically interesting question may therefore not be:

> Which professions can AI replace?

It may be:

> Which workflows can now be expressed as goals, tools, knowledge, and constraints rather than manually executed procedures?

That is a much larger category.

## Agentic automation, for dummies

After all that, my current definition is fairly boring:

> **Agentic automation is automation in which a reasoning model is delegated bounded judgment about how to achieve a goal.**

The important words are not *reasoning model*.

They are **delegated** and **bounded**.

Delegation means the machine gets to decide things that were previously decided by a human during execution.

Bounded means there is still a surrounding system defining:

- what it may access;
- what it may change;
- whose instructions count;
- what requires approval;
- what evidence must be retained;
- what it may spend;
- how its behavior is audited.

Without delegation, it is ordinary automation.

Without boundaries, it is a liability.

## Things I wish I had understood at the beginning

Do not begin by asking how autonomous the system can be.

Begin by asking what authority it actually needs.

Do not put unstable judgment into scripts merely because scripts feel safe.

Automate the stable mechanics and leave unresolved judgment visible.

Do not treat all natural-language input as equivalent.

Track provenance.

Do not let an agent silently inherit a human identity if you can avoid it.

Technical identity is part of authorization.

Do not let useful lessons disappear inside completed tickets.

Promote them into reusable, versioned knowledge.

Do not assume an LLM should perform deterministic work simply because it can.

Ordinary software is cheaper and more reliable at ordinary software things.

Do not design safety around the assumption that the model will reason the same way tomorrow.

Design around observable outcomes and reversible actions.

And perhaps most importantly:

**expect every solved problem to reveal a new problem one abstraction layer higher.**

At first the question is:

> Can it understand the bug?

Then:

> Can it modify the code?

Then:

> Can it test the change?

Then:

> Can it maintain the PR?

Then:

> Can it follow up without me?

Then:

> Who is allowed to instruct it?

Then:

> What counts as an instruction?

Then:

> How do we prove who authorized what?

At some point you realize you are no longer “prompt engineering.”

You are designing an information system whose execution engine happens to understand semantics.

That is much more interesting.

And, occasionally, much more terrifying.