And that was really the part that bothered me. Not just the cost, but the idea of paying for something I could not adapt to how he actually learns.

I have spent over twenty-five years working in technology, leading teams and shaping how systems are built, maintained, and used. I understand how software is structured, how important templates are, how much usability and integration matters. But I had not written code myself in over twenty years. I was certified as a web developer back when the web was young, and then life moved me into leading teams.

So when I started wondering how far AI had come when it came to actually building something, not writing a document, not summarizing information, but creating a working app from scratch—it felt worth finding out.

The Multiplication Project was born from two things at once: a curiosity about what AI could actually build, and a genuine desire to create something that helps my son reinforce multiplication in a way that goes beyond memorizing times tables. Not a quick fix, but something he could actually engage with.

Why iPhone, Why Xcode

The technical choices were simpler than they might sound. We are an Apple household, so an iPhone app was the obvious starting point. I already had my MacBook Pro, which I have been using to run a fully local AI setup for deeply personal content, something I wrote about in detail here:

Having that foundation made Xcode a natural next step. For building iOS apps it is purpose-built, and SwiftUI gives you a relatively clean way to build views without needing to wrestle with too much complexity upfront. For someone returning to development after a long gap, that simplicity mattered.

My boyfriend, who is an app developer himself, offered a few tips and tricks along the way which helped me move faster than I might have on my own. He has also noticed something similar to what I found, that working with Claude has felt more seamless and less messy than doing the same work in ChatGPT. He works directly in the CLI, while I have been using a mix of Claude chat and the coding assistant connected to Claude in Xcode. Different approaches, but a similar conclusion.

Coming Back to Development After Twenty Years

I want to be honest about what it felt like to open Xcode for the first time in this context. The interface itself was not as intimidating as I expected. I jumped in fairly quickly, which surprised me.

What tripped me up early was something small but genuinely confusing: the difference between the Canvas and the Simulator. The Canvas shows you a static preview of what a view looks like. The Simulator actually runs the app. I thought the Canvas was the Simulator, I kept wondering why certain things were not responding the way I expected until I understood that there was an actual separate Simulator window. Looking back, it was a silly mistake—embarrassing, but the kind you only make once.

I eventually enabled Developer Mode on my own iPhone to test directly on a real device. I understand what Developer Mode does, that it allows unverified apps and deeper system access, and I stay aware of that. Since the only app I was running on it was mine, it felt like a reasonable trade-off. The important thing is going in with open eyes rather than just clicking through settings without thinking.

There was also a very practical reason I moved to the phone. Emojis would not render properly in either the Canvas or the Simulator. On the actual device, they worked perfectly. Sometimes the answer to a technical problem is just: try it on the real thing.

Using the Right Tool for the Right Job

Those of you who have read my previous posts will know that I think carefully about which AI tool I use for what. Not all conversations belong in the same place. That principle showed up here too.

I used ChatGPT to plan the structure of the app, the overall flow, what views I would need, how the experience should work from a usability perspective. ChatGPT is where I think out loud, and for that kind of broad planning conversation it works well for me.

When it came to actually writing SwiftUI code, I switched to Claude. This was not a decision I made in advance. It happened naturally after I found myself struggling to get the results I wanted from ChatGPT for the coding work specifically. SwiftUI views have a particular structure, and I kept running into issues here and there. It was a bit frustrating. When I switched to Claude, that friction reduced. The code it produced had fewer issues and required less back and forth to get working.

This is just my experience so far, and it is still early. But for this specific kind of work, Claude felt like the better fit.

The Time Claude Deleted Its Own Best Work

This is the part of the story I want to tell carefully, because it is not a simple “AI made a mistake” moment. It is more interesting than that.

At one point I started a new chat within my project and asked Claude to summarize what I had been building before moving forward. The problem was that my prompt did not do a good job of describing the view structure and theme I had already established. Without that context, Claude built new views from scratch.

And they looked better than mine.

I noticed the difference and pointed it out. Claude’s response was something along the lines of: my versions were over-designed, let me rewrite all three files now cleanly. And then it deleted its own files and replaced them with simpler ones.

I did not want simpler. I was not at the stage of polishing the final design yet. I was still trying to get something basic and functional up and running first. But those better-looking views had caught my attention, and I wanted to keep them for later reference.

I had taken a screenshot coincidentally before it removed them. I did not have a copy of the code, I had already reapplyed the new files without knowing the better-looking views were removed, and I had not committed anything yet.

What struck me afterwards was not just that it deleted the files. It was how natural that decision was from its perspective. It was not thinking about preserving options or keeping something just in case. It was solving for the instruction I gave it.

The lesson I took from this was twofold. First, commit your code. That one is on me, and it is a lesson as old as development itself. Second, be specific in your prompts. Claude acted on what I asked, but what I asked did not include: please do not remove what you just built. Without clear context, it made a reasonable but frustrating call.

The Moment It Felt Real

The more I worked on the structure, the more I kept thinking about my son using it. Not in a general user sense, but very specifically, what would actually help him, what would confuse him, what would make him want to keep going.

There is a difference between code that runs in a simulator and something you hold in your hand.

When I tested the app on my iPhone, something shifted. It worked. It felt like an actual thing, not a project. My son was there when I tested it, and watching him interact with it, seeing him get excited, was one of those unexpected moments that makes a side project worth doing. He told me he wanted to build his own app.

That was the moment it shifted for me. Not because the app was working, but because it had crossed a line. From something I was experimenting with, to something that actually meant something to someone else.

Where I Have Landed

The Multiplication Project is still in progress. A few views are built, and there is more to do. But I have learned enough already to say a few things with some confidence.

AI does not replace the need to understand structure. If anything it makes structure more important, because a poorly framed prompt produces code that looks right but solves the wrong problem. My background in technology actually helped here more than I expected. Knowing what good structure looks like, even if I could not always write it from memory, meant I could recognize when something was off.

Choosing the right tool still matters. In my case, ChatGPT for thinking, Claude for coding. That division emerged from my experience, not from a plan.

And commit your code! Seriously… every time.

Maybe the most unexpected part of all of this is that I am learning something new, which has brought me genuine joy and excitement. I have reconnected with something I had not done in a very long time. Not as a developer in the traditional sense, but as someone building something again. Something that matters, for someone specific, in a way that no subscription fee would ever quite capture.

Recently I had a conversation with a friend and former colleague about AI being used inside workplace documentation. His company relies heavily on Atlassian Confluence to store internal processes, guides, and operational knowledge.

They had recently started using AI features that allow co-workers to ask questions and receive answers generated from the documentation in the system. Instead of searching through several pages and trying to piece together the right information, someone can simply ask a question and receive a summarized response.

During our conversation he told me something that surprised him, the AI assistant was returning answers that were clearly incorrect.

The responses themselves read perfectly fine. They were clear, well written, and structured like straightforward explanations. Anyone reading the answer who did not already know the correct process would have no reason to question it. The AI assistant presented the response as a factual answer.

The problem was that the information behind that answer was not always correct. In some cases it came from documentation that was outdated or no longer reflected the current way of working.

For someone who already understood the process, the mistake was easy to see. For someone simply trying to learn how something works, the answer would look completely trustworthy.

That is where the real challenge begins. When incorrect information is delivered in a confident and well-written way, it becomes much harder to recognize that something is wrong. How would a new user ever know the difference?

The Knowledge Behind the Answer

What stood out to me in that conversation was that the issue was not really the AI assistant itself. The real issue was the documentation behind it.

Most organizations build documentation over many years. Processes change, systems change or are replaced, organizational changes may move people around or out, and project teams move on to new work. Pages that were once accurate slowly become outdated. Sometimes they are updated in one place but not another. Sometimes the same process gets documented multiple times in slightly different ways.

Over time a knowledge base grows, but not always in a clean or consistent way.

Before AI, this mostly created inconvenience. If someone searched for information, they might find several different pages and have to read through them to figure out which one was most current. It took time, but the process forced people to interpret what they were reading.

AI changes that experience. Instead of reading multiple pages, someone asks a question and receives a single answer. The system looks across the documentation and generates what it believes is the best response.

The AI does not truly understand which document represents the current truth. It simply works with the information it can access.

If the knowledge base contains outdated or conflicting material, the AI can still produce an answer that sounds complete and convincing. It could also depend on the predefined prompts the AI assistant is configured to use.

It brings us back to one of the oldest sayings in computing: garbage in, garbage out.

The difference now is that the output can look very clear and convincing.

The Archiving Assumption

Another part of our conversation stayed with me. My colleague mentioned that some of the documentation influencing the answers had already been archived. At least, that was the assumption.

In systems like Confluence, archiving usually moves a page out of the main content tree and removes it from normal search results. But the content itself still exists in the system unless it is deleted. In some situations, such as links, indexing behavior, or search inconsistencies, archived content can still appear or remain accessible to systems reading the underlying data.

From the perspective of the person maintaining the documentation, the page feels like it has been removed. From the perspective of the system analyzing the knowledge base, the information may still be there.

For the employee asking a question, none of that background is visible. They simply see an answer that appears clear and confident. Would you even know if the response was correct or not?

If the answer is presented as a fact, there is little reason for someone to question whether it came from documentation that no longer reflects the current way of working.

Where Humans Still Matter

None of this means AI should be avoided in workplace knowledge systems.

Tools that help search and summarize documentation can be extremely useful. They reduce the time people spend digging through pages and help surface information that might otherwise stay hidden.

What changes is where human effort needs to go.

Instead of spending time searching for information, the more important work becomes maintaining the quality of the knowledge itself.

That starts with ownership. Important documentation should have someone responsible for reviewing it and keeping it accurate over time. Without clear ownership, outdated pages slowly build up and systems that rely on them will continue to use them.

Once an AI assistant starts answering questions, it can also help reveal problems in the documentation. One useful practice is asking documentation owners to occasionally test the system the same way an employee would. Instead of reading the page directly, they can ask the AI assistant questions about their own documentation and see what answer comes back. This allows them to see what users actually experience and catch situations where the system summarizes something incorrectly or pulls from outdated material.

AI can also help maintain the knowledge base itself. Organizations could use it to monitor documentation and flag content that has not been updated for a long time. Instead of aging quietly in the background, those pages could trigger reminders for a human review.

In this way, AI becomes part of the maintenance process, not just the interface for answers.

The important part is that the final responsibility still sits with people. AI can help surface information, highlight potential issues, and even suggest improvements. But someone still needs to decide whether the content reflects how the organization actually works today.

That is where the idea of a human in the loop becomes practical. AI can deliver knowledge faster than people could search for it themselves, but humans still need to confirm that the knowledge behind those answers is correct.

A Small Shift in Responsibility

What stands out to me about this shift is that AI does not remove the responsibility for maintaining documentation. In many ways it makes that responsibility more visible.

Before AI, messy documentation mostly slowed people down. Someone might spend extra time searching, ask a colleague for help, or eventually find the right page after reading several others.

Now the system often provides an answer immediately. That speed is helpful, but it also means the quality of the knowledge behind the system matters even more.

AI can connect information, summarize documents, and surface answers in seconds. What it cannot do is decide whether that information still reflects how the organization actually works.

That part still belongs to people.

If AI becomes the layer between employees and the knowledge they rely on, then the quality of that knowledge becomes part of the organization’s infrastructure.

It is no longer just documentation, it becomes part of how decisions are made.
And when outdated information is presented with confidence, it can look correct to anyone who doesn’t already know the difference.

Lately, I cannot scroll LinkedIn without noticing the em dash in product announcements, reflective leadership posts, AI commentary, and thoughtful threads that aim to sound conversational while remaining polished.

The punctuation mark itself is not new. It has long been one of the most flexible tools in written English. As explained by Merriam-Webster, “The em dash (—) can function like a comma, a colon, or parenthesis.”—signaling interruption, emphasis, or a shift in thought. When used intentionally, it adds rhythm and preserves the natural movement of a sentence in ways that stricter punctuation sometimes cannot.

This is not a complaint about grammar. This is my observation about saturation, what saturation can do to perception, and what in turn might change our culture of how we use or not use em dashes and other overused polished words due to AI all together.

What the Em Dash Used to Do

My curiosity about the em dash’s frequent appearance led me back to older books on my shelf. In my copy of Treasure Island, the em dash appears frequently in dialogue:

“Well, many’s the long night I’ve dreamed of cheese—toasted, mostly—and woke up again, and here I were.”

The em dash in this case lets the sentence move the way the character is talking, indicating his interrupted speech and and abrupt change of sentence. It keeps the rhythm uneven and slightly messy, which makes it feel human. It is there to preserve voice, not to make the sentence look refined.

I also noticed that in these older editions the em dash sits tightly between words, without spaces. In newer writing, there is often space around it. The rules seem to shift depending on where and how something is published. Maybe punctuation just adapts to technology and taste.

That evolution does not concern me.

When Style Becomes a Tell

My experience with language models is that they tend to produce polished, structured writing that values clarity and smooth flow. They connect ideas, they ease transitions, and often expand thoughts rather than shorten them. Over time, this creates a recognizable rhythm.

The em dash fits naturally into that rhythm because it lets a sentence shift direction without fully rewriting itself. It also adds emphasis without forcing the writer to be brief, and it gives the impression of reflection. Used occasionally, it feels thoughtful and when used repeatedly across millions of posts, it begins to feel familiar in a different way.

When large numbers of AI-assisted texts rely on similar rhythms and punctuation patterns, those patterns stop feeling like personal choices and start feeling like signatures. And once readers begin to associate those signatures with automation, credibility can quietly shift.

I wonder what kind of culture shift this will bring…

Reputational Drift

What concerns me is not misuse of the em dash, but what happens when repetition changes meaning.

If readers start to associate the em dash with AI-generated text, writers may begin avoiding it. We have seen similar shifts before. For example, visual styles lose their uniqueness when they are overused, stock imagery becomes easy to spot, and certain corporate phrases have lost their impact once they are repeated too often. The meaning changes through overexposure.

The deeper risk is not that AI writes incorrectly, it is that it writes in ways that start to look the same. When repetition reduces contrast, readers adjust. And sometimes that adjustment means stepping away from punctuations or words that were once simply part of normal expression.

Human in the Loop as Cultural Steward

Most conversations I read are about human oversight in AI focus on accuracy, bias, and safety. Those concerns are important, but if style can quietly change meaning through repetition, then oversight must include something more subtle: paying attention to how language shifts when patterns are repeated at scale.

AI systems do not just help us write, they repeat what they have learned. If a certain rhythm feels polished, it spreads. If a certain punctuation habit becomes common, it begins to look normal. Over time, repetition shapes expectation, and expectation changes how we interpret what we read.

This is where the human role matters. Not to only correct mistakes, but to notice sameness. And not only to approve content, but to decide when a sentence should be shorter, and when a dash should become a period, or when a thought should stand on its own. Human involvement does not have to be complicated, and it can be as simple as reading a draft once more and asking whether the rhythm feels chosen or automatic.

A small pause, a small edit, can slow that drift. These are small decisions, but at scale they protect variation instead of reinforcing sameness.

A Broader Pattern

The em dash is easy to notice, which makes it a useful example. It gives us something concrete to point to, but the larger issue is not about one punctuation mark. It is about what happens when small writing habits are repeated so often that they begin to feel generated.

When AI systems generate text, they usually repeat patterns they have learned. If a certain rhythm or stylistic choice appears often enough, it can start to look like the default. Over time, readers will most likely connect those patterns with automation, even if the pattern itself was once a normal and expressive part of writing. I can almost hear it now: “Oh this reads like it was AI generated with all of these em dashes, maybe I shouldn’t use them in my post.”

And it’s not just em dashes. I have also read plenty of articles where people list words you shouldn’t use in your prompts because they are “AI words”.
Why?—these words are often used in AI outputs. “Sigh”

If repetition can slowly change how we interpret style, then it is worth asking how much of that repetition we want to let pass without reflection. The em dash may simply be visible right now because it is easy to spot. But it makes me wonder what other small habits, including certain words, are quietly becoming signals, and whether we will notice before they begin to shape how we write.

If a punctuation mark or even an ordinary word becomes strongly linked to automation, I can’t help but wonder how that might shape writing culture in the long run.

• ChatGPT for thinking and exploration.

• AWS Bedrock with AnythingLLM for professional work.

• And, eventually, local models for things that should never leave the house.

I ended that post by saying I would come back once I had actually tested that last category.

This is that follow-up. Over the course of about a week, roughly eight hours spread across evenings, I tried to answer a very specific question:

Is it realistically possible to run a fully local AI setup for deeply personal content and actually trust it?

Not as a demo, not as a research project, but as something I could genuinely use.

A Quick Orientation Before I Go Further

Before getting into what worked and what didn’t, it helps to be clear what I started with, what actually changed over the week, and under what circumstances.

I started with a fairly straightforward setup. My MacBook Pro M2 with 16 GB of memory, Ollama to pull local models and AnythingLLM as the interface. I had a single-pass approach where I tried to summarize everything at once, with early experiments using llama3.1:8b and qwen2.5:7b.

At this stage, my focus was on improving outcomes by adjusting prompts or swapping models, rather than questioning whether the overall structure made sense.

What I ended up with looked very different.

• Ollama as the local model runtime.

• A small Python script to orchestrate the work.

• Chunked processing, retries, and multi-stage summaries.

• Different models assigned to different roles.

As the structure improved, the model choices shifted with it. I moved from llama3.1:8b to mistral:7b-instruct for chunking and structured summaries, and from qwen2.5:7b to qwen2.5:14b for merging and higher-level synthesis.

Running all of this on my MacBook was the constraint. It’s why I stayed within these model ranges and focused on structure, traceability, and reliability rather than chasing larger models.

Looking back, that shift from asking the model to do everything to designing a process it could reliably execute is what set the rest of the week on the right track.

Why I Wanted to Do This at All

This wasn’t driven by general AI curiosity. I already use AI every day.

What pushed me here was the nature of the data. I wanted help working with health and medical logs, school and family notes, and personal journals. Not to generate new content, but to summarize long, messy entries, surface patterns over time, and help me reason about what was already written.

Privacy wasn’t theoretical in this case. It was non-negotiable.

I wasn’t comfortable putting this kind of material into any cloud system, regardless of terms, promises, or safeguards. For this category of information, the only acceptable answer was that it stays on my machine.

At the same time, I didn’t want a fragile experiment that only worked on a good day. I wanted something I felt comfortable with.

ChatGPT Was Part of the Process

I didn’t figure this out in isolation.

From the beginning, I used ChatGPT as a thinking partner while working through the setup. Not to ask for a perfect solution, but to talk through what I was trying to do, what wasn’t working, and what felt wrong about the outputs I was getting.

There were many back-and-forth conversations. I would try something, see it fail in subtle ways, describe the failure, adjust the approach, and try again.

In that sense, the process mirrored how I already use ChatGPT. It wasn’t there to replace my judgment. It helped me think through trade-offs, structure problems, and constraints until I saw the light at the end of the tunnel.

That matters, because this isn’t a story about abandoning cloud AI. It’s a story about using it on purpose to get to use something I could then run privately.

Where It Got Frustrating

My first thoughts were to just dump everything in, ask for a summary, and wait.

Well… that didn’t work. Silly me.

Sometimes the output looked fine at first glance, but important early data was missing. Date ranges were wrong, summaries were far shorter than they should have been, and what made this uncomfortable wasn’t the failure itself, but how confident the failures looked.

There were moments where I genuinely wondered if this was worth the effort. It felt tedious to keep rerunning things and not get the result I wanted.

Around the same time, I realized that while AnythingLLM worked well for other contexts I use it in, it became friction once I needed tighter control. I needed chunking, retries, validation, and multi-stage processing. At that point, the interface slowed me down rather than helping.

Eventually, one thing became clear. This wasn’t a prompting problem, and it wasn’t a model problem. It was a structure problem.

The Shift That Changed Everything

The breakthrough came when I stopped treating the data like a blob and started treating it like a book.

Instead of asking one model to understand everything at once, I split the work into stages. Small chunks processed consistently, summaries built on top of those, and higher-level synthesis layered above that.

This wasn’t solved with better prompts alone. I ended up using a small Python script to run the process. It handled chunking the data, running structured summaries, retrying when something failed, and then merging the results. Once that structure was in place, prompts still mattered, but they stopped being the primary bottleneck. Structure determined what was even possible; prompts fine-tuned the result.

I also stopped trying to make one model do everything. Some models were better at strict structure. Others were better at synthesis and pattern recognition.

Once each model had a clearly defined role, the outputs changed completely. They became complete, traceable, and trustworthy.

At every stage, I could move backwards from a high-level overview to a yearly summary, to a chunk, to the original entry. That mattered more to me than speed.

When It Stopped Feeling Like an Experiment

Somewhere around the middle of the week, after chunking was in place and I allowed myself to use a slightly larger model for synthesis, I ran the pipeline again and immediately knew.

This was it!

The output matched what I had hoped for from the beginning.

• Nothing important missing.

• No invented certainty.

• No over-compression.

From that point on, the work shifted. I wasn’t wondering whether this was viable anymore, I was just fine-tuning details.

This wasn’t instant either. A full run took a couple of hours on my laptop, not seconds, but it ran unattended and produced something I could actually trust.

That was the moment it stopped feeling like an experiment and started feeling like a tool.

Locking It Down Without Making It Dramatic

All of this ran locally using Ollama as the model runtime.

Once the models were downloaded, I removed any ambiguity about where data could go. I blocked Ollama and AnythingLLM from all network access using the macOS firewall. I even blocked Terminal while running the Python script that ran the pipeline. That was probably overkill. What I wanted was:

• All files staying local.

• No external APIs.

• No background connections.

• No searching for content on the internet.

At no point did this data touch the cloud, not implicitly and not accidentally.

This wasn’t about paranoia. It was about being able to say, with confidence, that I knew where the walls were.

What I Learned Along the Way

A few things became very clear for me.

• Bigger models reduce some failure modes, but they don’t compensate for missing structure.

• Context limits fail quietly and confidently, often producing outputs that look reasonable while being incomplete or wrong.

• Structure sets the ceiling for what prompting can achieve. Prompts still matter, but they can’t rescue an unstructured process.

Trust did not come from how good the summaries looked. It came from being able to trace every conclusion back through layers to the original entries. Without that traceability, I wouldn’t have used the output at all.

One small but important lesson was about ambiguity. In early runs, the model tried to be helpful by expanding initials or resolving unclear references. This wasn’t acceptable.

I added explicit guardrails. Do not guess, do not expand, do not resolve ambiguity unless it is explicitly stated.

With this kind of data, preserving uncertainty is often the most honest outcome.

Who This Is and Is Not For

This setup makes sense if you deal with sensitive personal or family data, want long-term summaries you can actually trust, and are comfortable reading scripts and thinking in systems.

It’s probably not worth it if you just want quick brainstorming, don’t care where data lives, or want something that works instantly with no setup.

This feels much closer to building a small personal tool than installing an app.

Where I Have Landed

After a week of testing, I trust this approach for personal and family logs, the kind of information I would never want leaked.

I don’t think everyone needs to run local AI and I don’t think the cloud is inherently wrong.

I am more convinced than ever of the idea I ended my previous post with.

• Not all AI conversations deserve the same environment.

• Some are low-risk.

• Some are professional.

• And some are personal enough to require walls, not windows.

As AI becomes more embedded in daily life, as planners, journals, and confidants, privacy literacy matters more than ever.

Not fear, not paranoia, just thoughtful judgment about where information lives and who ultimately owns it.

Agentic AI represents a shift from isolated AI tools to interconnected, autonomous systems that reason, plan, act, and adapt over time. That shift changes not only what organizations build, but how decisions are governed, owned, and operationalized.

A note on perspective:
The platforms and examples referenced in this post are drawn from my own experience and recent training in an AWS context. This is not an endorsement of any single vendor, nor a claim that these approaches are exclusive to AWS. The principles discussed, including autonomy boundaries, governance, observability, partner readiness, and organizational preparation, apply regardless of cloud provider or technology stack.

From Generative AI to Agentic AI: Why This Matters

Generative AI assists humans with tasks.
Agentic AI takes action.

Agentic systems:

• Maintain context over time

• Coordinate multiple agents

• Execute multi-step workflows

• Adapt based on outcomes

• Operate with increasing autonomy

This unlocks significant value, but it also introduces new risk. Most failures do not come from hallucinations or model limitations. They come from unclear ownership, undefined autonomy, and missing operational guardrails.

The Question Decision-Makers Often Skip

Before asking “Which partner should we work with?”, a more important question is:

What are we actually ready for as an organization?

Agentic AI does not create problems. It exposes existing ones:

• Data quality issues

• Process gaps

• Governance ambiguity

• Risk tolerance mismatches

The earlier these are surfaced, the more successful any implementation will be.

What Decision-Makers Should Clarify Internally First

1. Strategic Intent

• What business outcome are we trying to improve?

• Are we optimizing an existing process or redesigning it?

• Is this exploratory, or are we expecting production impact?

Agentic AI delivers the most value when goals are explicit.

2. Autonomy and Risk Boundaries

• Which decisions may an agent make autonomously?

• Which decisions must always involve human approval?

• What is our tolerance for incorrect actions?

• Who owns accountability when an agent acts?

Autonomy without boundaries creates operational risk.

3. Data Readiness

• Which systems will agents access?

• Do we trust the quality of that data?

• What data must never be accessed autonomously?

Agentic AI amplifies both good and bad data.

4. Operating Model

• Who monitors agents after deployment?

• How are incidents handled?

• How do we roll back incorrect actions?

• How do we increase autonomy safely over time?

Agentic AI requires ongoing operations, not just deployment.

What to Prepare Before Engaging a Partner

Organizations move faster when they prepare a small but focused set of inputs:

• A concise problem statement

• Defined autonomy limits

• A high-level data inventory

• Timeline expectations

• Clear success criteria

This preparation reduces friction and avoids misaligned expectations.

Questions Every Decision-Maker Should Ask a Partner

Production Readiness

• How do you take agents from prototype to production?

• How do you handle long-running workflows?

• How do you manage agent state and memory?

Safety and Governance

• How is human-in-the-loop implemented?

• How do you prevent uncontrolled agent behavior?

• How are confidence thresholds and rollback handled?

Observability

• Can we trace why an agent made a decision?

• Are agent actions logged and auditable?

• How is agent performance measured over time?

Clear answers here matter more than feature lists.

Choosing an Adoption Path

Based on common enterprise patterns, organizations typically choose one of three paths.

Ready-to-Use Solutions

• Fast deployment

• Lower risk

• Limited customization

Custom-Built Agents

• Full control

• Higher investment

• Greater long-term differentiation

Partner-Led Implementations

• Balance between speed and customization

• Industry-specific expertise

• Reduced delivery risk

The right choice depends on risk tolerance, internal capability, and desired differentiation.

Final Thought

Agentic AI introduces new actors into enterprise systems. These are systems that make decisions, take actions, and learn over time.

Organizations that succeed:

• Think before they build

• Define boundaries before autonomy

• Treat agents as operational participants, not tools

The most important work happens before the first partner meeting.

When I finally committed to using it more intentionally, I expected just another set of videos to watch. What I found instead was an engaging, role based learning experience that made me wonder:

“Why did I wait so long to do this?”

What Hooked Me: Role Based Learning and Hands On Labs

AWS Skill Builder’s structure stands out. You choose a learning path based on your goals or job responsibilities, and the platform guides you through content that builds in a logical order. Instead of being overwhelmed by hundreds of AWS services, you get a clear route that focuses your attention.

Along with the courses, the platform offers hands on labs that place you directly inside AWS environments. This is where Skill Builder becomes valuable. You are not just remembering information. You are deploying services, modifying configurations, troubleshooting, and learning from real outcomes without risking a production environment.

Each lab follows a three stage progression that helps the concepts stick:

Learn
Clear visual diagrams outline what you are about to build and how AWS services fit together.

Practice
You step into the AWS Console and walk through the implementation.

DIY
A slight twist forces you to apply what you have learned without step by step guidance.

This structure moves you from understanding to action. It builds real confidence because you are not only shown what to do. You prove that you can do it.

Reinforcing What I Know and Exploring What I Do Not

I began with the Cloud Quest Practitioner path because it aligned with my existing experience. It was familiar enough to be comfortable, yet detailed enough to be interesting. It refreshed concepts I already used while introducing areas I had not explored in depth.

I am now working through the Networking path. Networking is something I have used for years, yet I continue to find new perspectives and clarifications that improve my understanding. It is a good feeling when something you thought you were familiar with becomes clearer and more meaningful.

There is something satisfying about realizing that there is always more to learn, even in topics you work with regularly.

When Game Meets Cloud: Pets, Drones, and Motivation

One of the biggest surprises is the addition of playful game elements in Cloud Quest, the interactive portion of Skill Builder. While completing quests, I encountered features that reward progress in unexpected ways. I have collected virtual pets by answering quizzes correctly and zapped drones that trigger short knowledge checks. Successful answers reward AWS themed cards that help with challenges.

These game elements never block your progress, and you can choose to ignore them. For me, they added moments of enjoyment that broke up the learning flow and made the experience memorable in a way that a traditional training portal usually does not.

AWS Maintains Content

Early in my journey, I ran into a lab that did not match the current AWS Console. I could not complete it, and I assumed it would take weeks to correct.

I stepped away from it and did not check back until three days later. When I returned, the lab was already updated. It may have been fixed sooner, but the important part was that the issue did not linger.

This responsiveness matters. It shows that AWS pays attention to Skill Builder and keeps it aligned with the platform it teaches. When a learning tool stays current, the time you invest in it feels worthwhile.

A Balanced View

Skill Builder is not perfect. The graphics in Cloud Quest feel dated, and the character movement on the map can be clunky at times. It has the structure of a quest style environment, but the visual quality and navigation do not quite match what many people might expect from modern quest based experiences. These elements do not ruin the learning, but they can occasionally distract from it.

The content, however, is strong. The labs, diagrams, and real console access build confidence that lasts beyond the lesson. That is where the platform proves its value.

The Biggest Benefit I Have Gained

Skill Builder has given me hands on experience with topics I had not explored deeply before, and it is refreshing to learn something new.

I have connected services more clearly, reduced confusion in areas I once found complex, and strengthened my ability to work confidently with AWS.

That feels like meaningful progress.

Would I Recommend AWS Skill Builder

Yes. Without hesitation. If you want to explore it yourself, you can find AWS Skill Builder here: https://skillbuilder.aws/

Whether you are new to AWS, preparing for a certification, or already using AWS services and want to expand your skill set, Skill Builder provides practical and focused paths that help you grow.

If your role involves AWS today, Skill Builder is also a smart way to explore services you do not currently use. Many people get comfortable with what they already know and miss opportunities to broaden their capabilities. Skill Builder encourages you to explore more of the platform in a guided way.

It is worth discussing with your manager as part of your professional development. Organizations benefit when employees understand the tools they work with. Skill Builder is a relatively small investment that can unlock a great deal of value for both you and your team.

You may not fall in love with every part of the interface, but you will appreciate what you walk away with.

Why Continual Learning Matters

The most important lesson I took away from this experience is not about AWS itself. It is about the process of learning.

Skills do not improve on their own. You have to nurture them. When you explore something that interests you, or step slightly beyond your comfort zone, learning becomes energizing rather than draining.

Curiosity turns effort into progress.

Whether it is AWS Skill Builder or something else entirely, the idea is simple:

Find something that engages you. Lean into it. Keep learning.

Over that time, after more than a year using ChatGPT, AWS Bedrock, and Anything LLM, I’ve noticed patterns in how I use each. These are my observations, not hard rules. This is how I see it.

Even as AI evolves rapidly, how we use it has to evolve too.

Because what started as a single tool in my workflow has gradually become three very different ones, each with its own purpose.

A Tool Is Only as Smart as Its Context

There’s a saying I love:

A fool with a tool is still a fool.

The more I used different AI systems, the more I realized that context matters as much as capability.

The question stopped being:
“What can the model do?”
and became:
“Where should this conversation happen?”

1. ChatGPT: My Thinking Partner

ChatGPT is where I go when I need to think out loud with something that can keep up. It’s fast, conversational, and surprisingly good at turning rough ideas into structured concepts.

• I’ve always kept security in mind: I don’t copy, paste, or share sensitive information.

• For casual thinking, problem-solving, and general exploration, the cloud works fine.

• Privacy nuance: The difference between ChatGPT and AWS/Anything LLM is minimal for typical users. The real jump in privacy only happens when you go fully local.

2. AWS + Anything LLM: The Professional Workhorse

At work, I need slightly different rules: governance, audit trails, and data privacy. AWS Bedrock with Anything LLM gives me that.

• Summarize documents

• Draft internal writing

• Reason through workflows

It’s not as frictionless as ChatGPT, but ideal for enterprise-level work. Most individuals won’t use advanced security features like IAM, VPC endpoints, or customer-managed keys, so for typical use AWS is mostly similar to ChatGPT in practical privacy.

3. Local Models: The Next Step

Then there’s the third category: the things that should never leave the house.

• Journals

• Family notes

• Deeply personal content

For that, the only real solution is a fully local model: self-hosted, no telemetry, no third-party logs. I haven’t deployed it yet, but I’m excited to get started.

It requires more work, hardware, and responsibility, but for content involving the people you care most about, it’s worth it.

The Big Lesson

After over a year of using these platforms, I’ve come to a simple conclusion. This is just my view:

Not all AI conversations deserve the same environment.

• Some discussions are low-risk.

• Some are professional.

• Some are personal enough to require walls, not windows.

As AI becomes part of daily life: planners, journals, confidants, we need a new skill: privacy literacy.

Not paranoia. Not fear.
Just thoughtful decision-making about where information lives and who ultimately owns it.

Where I’ve Landed

• ChatGPT: fast thinking, creative clarity

• AWS + Anything LLM: work, structured reasoning

• Local models: personal journaling and family data (coming soon)

Three tools.
Three contexts.
A much healthier relationship between information and risk.

AI keeps evolving fast, and if we want to use it well, we can’t just learn new features. We have to learn new judgment.

Because a fool with a tool is still a fool… and AI isn’t here to replace that wisdom.
It’s here to make it matter even more.