I Needed Another Me, So I Built Kage

Kage started because I wanted to be everywhere at once.

I was not trying to build another chatbot. I wanted something more personal than that. I wanted an agent that understood how I think, knew what mattered to me, and could make decisions close to the way I would.

Basically, I wanted another version of myself that could help carry the load.

My background is in investigations, fraud, risk, and compliance, so I approached the idea differently than someone coming from a traditional coding background might. Before I thought about everything the agent could do, I thought about where it needed to stop.

I built guardrails around behavior, permissions, personal information, money, legal risk, employment decisions, and anything else that could create a real consequence. I also built a profile of myself that included more than basic facts. I added my goals, preferences, priorities, work style, and the way I usually compare options.

The goal was not to make a blind copy of me. It was to give it enough context to act like an extension of me while still staying inside clear boundaries.

The basic idea was:

$$ \text{Decision} = \text{My priorities} + \text{Available information} + \text{Safety rules} $$

Kage could research, sort, compare, draft, and prepare actions. But anything important still needed to come back to me for approval.

Kage could research, sort, compare, draft, and prepare actions. But anything important still needed to come back to me for approval.

That was the foundation.

I started with problems I actually had

I had never used Codex before this project.

Most of my AI experience came from an LLM suite at work that, to be honest, is not very good compared with what Codex and SOL can do. I did not start with a technical roadmap or a clear picture of the final product. I just had an idea I wanted to test.

The first things I wanted Kage to help with were cleaning up my personal email and looking for better jobs.

Both sounded simple until I started breaking them down.

Email cleanup is not just deleting promotions. A generic store ad is probably useless, but a message from a bank, recruiter, loan servicer, attorney, or account-security team could be important. Even senders like LinkedIn can produce both junk and messages that matter.

Kage needed rules for what to keep, what to review, what could be archived, and what should never be touched without my approval.

The job search had even more requirements.

I did not want a tool that found every job with a matching title. I wanted it to consider salary, commute, remote eligibility, realistic fit, career growth, schedule, autonomy, and whether the company or posting looked legitimate.

I also wanted it to help prepare applications and eventually automate parts of that process, but only when the job met strict requirements.

It could find opportunities, compare them, rank them, prepare materials, and tell me which ones were worth my time.

It could not silently apply for jobs, make commitments, or answer sensitive questions for me.

That was my first real version of the twin idea: let it handle repetitive work, but keep me in control of the decisions that matter.

I hit a problem almost immediately

On the second day, I was at work and the project was sitting on my home computer.

I had built something that was supposed to help me, but I could not reach it when I actually had time to keep working on it.

I found the remote connection between ChatGPT and Codex, which was great at first. It gave me a way back into the project without being at home.

But it also felt clunky.

There were disconnects, unclear states, and not enough direction around what was happening or what I could do next. It worked, but it did not feel like the kind of reliable connection I wanted for Kage.

So I started building around that problem.

I created a universal bridge for my tasks and started working on a mobile web interface that could connect back to my computer. I wanted to be able to see the work, continue it, approve actions, and keep things moving from my phone or another location.

That changed the project.

Kage was no longer just a personal assistant running on one computer. It was becoming a way for me to reach my computer, my tools, and my projects from anywhere.

A lot of Kage has been built like that. I run into a real problem, figure out why it matters, and then turn the solution into part of the system.

$$\text{Problem} \rightarrow \text{Fix} \rightarrow \text{New feature} \rightarrow \text{Bigger idea}$$

There was never a clean roadmap. The project grew from what I actually needed.

Python finally made sense to me

About a week into the project, after adding features and spending a lot of nights working with Codex, something finally clicked.

Python is storytelling

I read a lot, and stories are one of the main ways I understand complicated ideas. Once I started looking at code through that lens, it stopped feeling like a wall of technical language.

A variable is information the story needs to remember.

A function is a scene with a purpose.

An if statement is a decision.

A loop is something happening again until the situation changes.

An input introduces new information.

An output is what happens because of everything that came before it.

An error means the story reached a point where something was missing, out of order, or impossible.

That way of thinking helped me understand what Codex was doing and why it was doing it. It also made errors less frustrating.

Instead of staring at an error message and thinking I had no idea what was wrong, I could ask:

• What was supposed to happen here?
• What information is missing?
• Which step happened in the wrong order?
• What condition did the program expect?
• Where did the story stop making sense?

I did not suddenly become an experienced programmer. I just found a way to understand the logic using a medium my brain already knew.

That also helped me give better instructions to Codex. I could describe the sequence, the rules, the decisions, and the result I wanted. Codex could help translate that into code.

That was one of the biggest lessons from the project:

People do not always need to learn technology through the language it was traditionally taught in. Sometimes the technology needs to be explained through the language the person already understands.

Then the project started getting too big

I have ADD, so once the project started working, it also started spreading in every direction.

One feature created three more ideas.

Email cleanup led to job searching. Job searching led to decision profiles and application rules. Remote access led to the bridge. The bridge led to a mobile interface. Then I started thinking about learning, memory, and how Kage should grow over time.

I had already added learning tasks so Kage could improve. But I had also seen what happens to a lot of agents when they try to remember everything.

They get bloated.

They collect old conversations, temporary details, failed attempts, duplicate instructions, and information that does not matter anymore. Eventually, the memory becomes more of a burden than an advantage.

That made me think about how people remember things.

We do not keep every detail from every normal day. Most of it disappears because it has no future value.

But we do remember things that are important, useful, unusual, relevant, or interesting.

That became one of the most important ideas in Kage.

The shadow idea

I started thinking about each task as something Kage could send out as a shadow.

The shadow would receive a specific mission, the tools needed for that mission, and clear limits on what it was allowed to do.

It could complete the task without forcing the main Kage system to carry every temporary detail forever.

When the work was done, the routine parts could be forgotten.

But if the task uncovered something important, useful, relevant, or even just interesting, the shadow could return with that information.

The memory rule became:

$$ \text{Keep}(x)= \begin{cases} 1, & \text{if } x \text{ is important, reusable, relevant, or interesting} \ 0, & \text{if } x \text{ is routine, temporary, or disposable} \end{cases} $$

The shadow does not need to return with every click, message, draft, or failed attempt.

It returns with what deserves to become experience.

That helped solve several problems at the same time.

It improved speed because Kage did not need to load every old task into every new one.

It improved safety because each shadow could receive only the permissions required for its job.

It improved focus because one mission could stay separate from another.

It improved memory because Kage could grow without trying to remember everything.

The shadow started as a way to control task memory, but it became the core idea behind the project.

Kage is the stable version of the agent.

The shadow goes out with a mission.

It works inside defined boundaries.

It returns with evidence.

Kage keeps what matters and lets the rest go.

Most of this was built at night

The nights became the real building blocks of Kage.

I would go through my normal day, notice a problem or think of something I wished the system could do, and then work on it at night.

Some nights I made real progress.

Some nights I broke things.

Some nights I spent hours solving something that looked small.

Other nights one idea changed the entire direction of the project.

The bridge came from being unable to reach my home computer.

The mobile interface came from wanting to keep building away from my desk.

The storytelling approach came from struggling to understand Python.

The shadow model came from watching the project and the agent memory become too large.

Kage was not built from one perfect plan. It was built from a series of problems, late-night ideas, mistakes, and moments where something finally made sense.

What I learned

I learned that I already had useful building skills, even though they did not look like traditional software-development skills.

My risk and compliance background helped me design guardrails, approvals, permissions, and escalation points.

My investigation experience helped me think about evidence, conflicting information, suspicious behavior, and what should happen when facts are incomplete.

My frustration with weaker AI tools helped me see where the experience could be better.

My reading habits helped me understand code as narrative.

Even my ADD and tendency to jump between ideas contributed to the task and memory model that became central to Kage.

I also learned that errors are often telling you what the design is missing.

The home-computer problem led to the bridge.

The remote-access issues led to a better interface.

Agent bloat led to selective memory.

My difficulty understanding Python led to the idea of adapting development to different ways of thinking.

The project did not grow around those problems.

It grew because of them.

Where I want to take it

Kage started as something built around me.

Eventually, I want to share it as a blank state.

A new Kage would not begin with my interests, my visual style, my priorities, or my way of processing information. It would learn the person using it.

It would learn what they care about, how they make decisions, what they enjoy, and how they naturally understand complicated ideas.

Then it could begin developing a personal online and phone interface around that user.

The goal is not to give every person the same coding dashboard.

The goal is to let Kage adapt coding to the way that person already thinks.

A musician might understand programming through rhythm, composition, tempo, and arrangement. Functions could feel like sections of a song. Loops could be rhythm. An error could be explained as something falling out of time or failing to resolve.

An artist might work through layers, composition, contrast, color, shape, and revision. Building software could feel closer to building an artwork.

A writer might understand code through characters, scenes, rules, choices, and consequences.

A teacher might see lessons, objectives, exercises, and outcomes.

A mechanic might see systems, components, diagnostics, and repairs.

A strategist might see goals, resources, constraints, risks, and decisions.

There are many ways people think.

Most development tools expect the person to adapt to the machine.

I want Kage to help the machine adapt to the person.

With SOL handling the technical depth, Kage could become the layer that translates someone’s natural thought process into working software.

$$ \text{Human idea} + \text{Personal Kage interface} + \text{SOL} = \text{Citizen development} $$

That is what citizen development means to me.

Not just giving non-developers easier buttons.

Giving people a real way to build useful projects through an interface that respects how their mind works.

One person’s Kage might feel like a recording studio.

Another might look like a sketchbook, workshop, library, laboratory, or command center.

The safety rules, task controls, permissions, and memory system would remain underneath it all. But the actual experience of building would belong to the user.

What Kage is now

I still do not know exactly what category Kage belongs in.

It is a personal agent.

It is a bridge to my computer.

It is a mobile interface.

It is a task system.

It is a controlled memory model.

It is also a way to help people understand coding through whatever medium makes sense to them.

Mostly, it is something I think is cool, something I enjoy building, and something I want other people to experience.

Kage started because I wanted to be everywhere at once.

What I ended up building was a version of that, something that can take part of my intent, go do the work, and return with what matters.

The ultimate expression of “if you want something done right, you are going to have to do it yourself” except now I can send another version of myself to help.

Built With

• chatgpt
• cloudflair
• codex
• google-drive
• grit
• openaiapi
• tailscale