Curiosity to Orchestration: My Journey with AI

By Brandon Askew — Founder, application developer, and AI systems builder

What does “curiosity to orchestration” mean?

Curiosity to orchestration is the shift from asking AI what it can do to designing systems where AI helps plan, build, review, test, improve, and support work under human direction. My journey with AI started with experimentation, but it became something deeper: a question of trust, accountability, process, agents, local models, and the responsibility of leading AI-supported systems well.

Where did the curiosity stage begin?

I did not come to AI as something completely unfamiliar. What changed was the moment it entered public awareness at scale. OpenAI introduced ChatGPT on November 30, 2022, and for many people that date marked the moment AI moved from an abstract idea into a tool they could actually touch. Source: OpenAI

Like a lot of people, I started with curiosity. I tested it. I played with it. I asked it to do creative, strange, and sometimes ridiculous things just to see what would happen. In those early days, AI felt like a new kind of tool, one that invited experimentation.

The question at the center of it all was simple:

What can this do?

That question carried me for a while.

I pushed on it from all kinds of directions. I asked it to write, explain, brainstorm, create images, make music, organize information, and help me understand how things worked. Sometimes it surprised me. Sometimes it missed badly. And sometimes it produced something polished enough to sound right without being solid enough to trust.

The lesson: Curiosity is the doorway into AI, but it is not the destination. The early excitement matters because it gets you experimenting. The next stage begins when the output has to be good enough to stand behind.

Why wasn’t capability enough?

That early stage was exciting, but it taught me something important very quickly:

Capability is not the same as trust.

Early on, one of the easiest traps is thinking you understand more than you do simply because the output sounds polished. AI can create the feeling of progress before you have actually done the work of understanding. That can be useful when it helps you move, but dangerous when it makes you stop questioning too soon.

How did trust change my AI practice?

If AI was going to become part of my real work, then trust mattered more than novelty. But trust with AI is not blind trust. Real trust starts when you stop taking the output at face value. It begins when you test it, challenge it, correct it, and make it earn its place in the process.

That was one of the first major shifts for me.

At some point, I stopped asking whether AI could give me something interesting and started asking whether it could help me create something I would actually stand behind. That is a different standard. The moment your name is on the work, the stakes change. The result has to reflect your judgment, your standards, and your responsibility.

AI can accelerate thinking, structure ideas, and move a project forward, but it does not remove human ownership. If anything, it makes ownership matter more.

That is where the relationship became more serious for me.

I had to get better at explaining what I wanted. I had to define success more clearly. I had to learn how to spot weak reasoning, shallow output, missing context, and overconfident answers. In doing that, I realized something else:

Challenging AI sharpens your own thinking.

When the output is weak, it forces you to ask better questions. Was the request unclear? Was the goal too vague? Did I leave out the right context? Did I ask for an answer before I had really defined what good looked like? AI did not just give me output. It pushed me to become more structured in how I think.

The lesson: Do not measure AI by how impressive the first answer sounds. Measure it by whether the answer survives review, correction, context, and responsibility.

How did prompting become process design?

Over time, I also stopped thinking only in terms of prompts and started thinking in terms of process.

At first, a prompt feels like the basic unit of work. You ask. It answers. You refine. You move on. But after a while, patterns begin to show up. Certain tasks repeat. Certain stages always follow others. A single answer can be useful, but a repeatable workflow is much more powerful.

That was the point where my thinking began to shift from using AI to building with AI.

The question changed again.

Instead of asking, “Can AI help me write this?” I started asking, “Can I build a workflow where AI helps gather context, shape a plan, draft the work, review the result, identify gaps, and prepare the next step?”

Instead of asking, “Can AI help me code this?” I started asking, “Can I break this project into clear tasks, assign those tasks, review the output, and move from idea to deployment in a structured way?”

That was the beginning of thinking in terms of agents and orchestration.

The Lesson: Prompting asks for an output. Orchestration designs the system around the output: context, sequence, review, testing, documentation, deployment, and improvement.

What is an agent in a useful sense?

An agent, at least in any useful sense, is more than a chatbot with a label. A useful agent has six things:

• a role,
• a goal,
• instructions,
• boundaries,
• context, and
• a definition of done.

This is also where the broader AI industry has been moving. On March 11, 2025, OpenAI introduced new tools for building agents, including the Responses API, built-in tools such as web search and file search, and the Agents SDK. Source: OpenAI

That matters because it shows a larger shift. AI is no longer only about a single model answering a single question. It is increasingly about systems where models use tools, follow instructions, preserve context, take steps, and return work that can be reviewed.

One agent can support a specific task. A team of agents can begin to reflect the shape of real work: research, planning, drafting, coding, testing, documenting, deploying, supporting, and improving.

What changes when you begin to manage AI?

When agents enter the workflow, the human role changes too.

You are no longer just prompting. You are setting the goal, designing the process, assigning the work, reviewing the output, and making the final call. You decide what good looks like. You decide what is acceptable and what is not.

In other words, you begin to manage AI.

That is a very different relationship from where I started.

I began with curiosity. Now I find myself thinking much more about orchestration. How do I connect the stages of work? How do I move from an idea, to a plan, to execution, to review, to deployment, to continuous improvement? How do I design systems where AI is useful without pretending that responsibility has somehow disappeared?

The Lesson: Orchestration is not about making AI independent of humans. It is about making the human role clearer: goal-setter, process designer, reviewer, decision-maker, and accountable owner.

Why does accountability matter more as AI gets closer to real outcomes?

That last part matters more and more the closer AI gets to real human outcomes.

One of the strongest cultural references I have found for this is Star Trek: Voyager and the episode “Latent Image.” What makes that episode relevant is not just that The Doctor is intelligent. It is that he is operating in a morally loaded situation where judgment carries human consequence. That is very different from simple task execution.

As AI moves closer to healthcare, operations, compliance, finance, and other areas where it can directly influence people’s lives, the real question is no longer just whether the system works. The real question is what happens when that system is close enough to judgment that trust, accountability, and consequence become unavoidable. At that point, we are no longer talking only about automation. We are talking about responsibility.

That is one of the deepest lessons in this journey for me.

The more capable AI becomes, the less this is about handing work off to a machine and the more it becomes about learning how to lead, evaluate, and govern systems that can shape real outcomes. As the technology grows in reach, judgment, oversight, and accountability move even closer to the center.

The Lesson: The closer AI gets to decisions that affect people, the more important it becomes to design for review, accountability, and human judgment from the beginning.

What does orchestration look like in software development?

That idea carries through even in software development, where orchestration has become one of the most interesting parts of the work for me.

The lifecycle is no longer just write something and ship it. It becomes:

concept → plan → build → test → deploy → support → update → repeat

That is where systems like Symphony, Claude Code, and Codex became interesting to me. Claude Code describes itself as an agentic coding tool that lives in the terminal, understands a codebase, and helps execute routine coding tasks, explanations, and git workflows. Source: Anthropic Claude Code GitHub

OpenAI introduced Codex on May 16, 2025 as a cloud-based software engineering agent that can work on many tasks in parallel. OpenAI also describes Codex tasks as running in isolated cloud environments and typically taking between 1 and 30 minutes depending on complexity. Source: OpenAI

I do not see those tools as interesting only because they make coding faster. I see them as signs of something bigger: AI participating across the full lifecycle of work. An idea becomes a plan. The plan becomes issues. The issues become assignments. The assignments become output. The output gets reviewed, tested, documented, deployed, and improved.

That is not just prompting anymore.

That is orchestration.

And orchestration requires a different mindset. It requires clarity, structure, patience, and standards. It requires allowing the system to do useful work while keeping human judgment firmly in the center. AI agents are not magic employees. They need direction, context, constraints, review, and accountability.

In many ways, this starts to feel less like using software and more like leading a team.

The lesson: Once AI participates in multiple stages of a workflow, the main job is no longer just prompting. It becomes coordination, review, and standards.

Why do local LLMs matter?

That shift has also made me think much more about the economics behind AI.

When every request has a cost attached to it, it affects how you work. It changes how much context you give. It influences whether you explore multiple approaches. It shapes whether you let an agent research, retry, compare, document, and refine. The meter changes behavior, and it can make you smaller in your thinking than the work itself deserves.

That is one reason I have become increasingly interested in local LLMs.

Local AI is not just about saving money. It is about freedom. Freedom to experiment more. Freedom to keep private context closer. Freedom to build longer-running systems without feeling every step through the cost of tokens. Freedom to create workflows shaped by the needs of the work, not just the pricing model behind the tool.

At the same time, local AI brings its own realities. If you want to move from a single chat into true multi-agent workflows, then hardware matters. Infrastructure matters. Compute matters. The machine behind the model matters.

That is why I do not see the future as cloud versus local.

I see it as hybrid.

Use hosted frontier models when the task needs maximum reasoning power. Use local models when the work needs privacy, repetition, experimentation, or more room to run. The real skill will be learning how to use both intentionally. For me, the question is not which model is best in the abstract. The question is which model belongs in which part of the workflow.

What does the human still own?

Ultimately, this whole journey feels like it is becoming about more than productivity.

It is becoming about ownership at every level: the work itself, the process behind it, the infrastructure supporting it, and the responsibility for what it ultimately produces.

That is the thread that connects everything for me.

At first, AI was a curiosity.

What started as a tool gradually became something more: first a collaborator, then an agent, and eventually part of a larger coordinated system.

The more I work with AI, the more I believe the important question is no longer just:

What can AI do?

The better question is:

What kind of system can I build with AI, and what kind of human do I need to become to lead it well?

That is the part that interests me most.

AI has pushed me to become clearer, more skeptical, more structured, more creative, and more willing to experiment. It has also pushed me to think more deeply about trust, accountability, privacy, economics, infrastructure, and leadership.

That is really what this series is about.

It is about moving from curiosity to trust. From trust to challenge. From challenge to growth. From prompts to agents. From agents to orchestration. And now, increasingly, from simple use of AI into the much more serious work of leading AI-supported systems that can affect real outcomes in the world.

Because this is not just a story about technology.

It is a story about how the work changes.

And how we change with it.

FAQ: Curiosity to Orchestration

What does curiosity to orchestration mean?

Curiosity to orchestration describes the journey from experimenting with AI prompts to designing AI-supported workflows, agents, and systems that still depend on human judgment.

What is the difference between prompting and orchestration?

Prompting is asking AI for an output. Orchestration is designing the full process around that output: context, sequence, review, testing, documentation, deployment, feedback, and responsibility.

What is an AI agent?

A useful AI agent is a role inside a workflow. It has a goal, instructions, boundaries, context, and a definition of done. It is not valuable because it has a label; it is valuable when it helps complete a clearly defined part of the work.

Why does human oversight still matter with AI agents?

Human oversight matters because AI can assist with work, but humans still define the goal, set the standards, review the output, protect sensitive context, and decide when the work is ready.

Why do local LLMs matter?

Local LLMs can give builders more privacy, control, and freedom to experiment, especially when workflows require repeated use, sensitive context, or longer-running systems. The future is likely hybrid: hosted frontier models for maximum capability and local models for privacy, repetition, and control.