AI Is Everywhere. What Do You Build Next?

TL;DR: AI is moving into phones, software, connected devices, and the workflows people use every day. That is a reason to be more deliberate about privacy, context, permissions, and accountability. It is also an opportunity. Instead of waiting to see what AI does to you, identify a real problem, define the outcome you want, and use the smallest reliable system to make the work better. This is an unscripted AI With Honor conversation from Connor MacIvor about practical building, not a promise that every tool is safe or that every business needs an autonomous agent.

AI is everywhere now, or at least the conversation about it is. It is in the phone in your pocket, the television on the wall, the business software that follows up with a lead, the camera on a doorbell, the search box in a browser, and the systems that decide what gets put in front of us next. That can feel like one big, vague force moving faster than ordinary people can understand.

The useful response is not panic. It is not pretending that every new feature is harmless either. The useful response is to slow the question down enough to ask what is actually happening, what information is being shared, what outcome is being created, who remains responsible, and whether the tool is helping solve a real problem.

In this unscripted AI With Honor episode, I am talking through that tension. I am interested in the practical upside of AI because I use these tools to build. I am also interested in the limits, the privacy questions, the provider questions, and the moments when an impressive tool can make us forget to use judgment.

Privacy is a practice, not a panic button

The first part of the conversation is about privacy. Connected devices and online services regularly ask us to accept terms, permissions, and settings that most people do not read closely. That does not mean every service is doing the same thing, and it does not prove a particular company is using information in a particular way. It does mean that a quick tap on "agree" is not the same as a careful decision.

Privacy is not one setting. It is a series of choices.

What account are you using? What plan are you on? What does the provider say about retention and training? What integrations have access to your contacts, files, calendar, customer records, or microphone? Can you remove information later? Does the project need the full record, or only a less sensitive summary? Who else in the business can see the output?

Those questions are not glamorous, but they are the difference between using a tool on purpose and simply handing the tool whatever it asks for. The right answer is not always "do not use it." A business may reasonably choose a hosted AI service because it is useful, affordable, and maintained by a capable provider. Another business may choose a more private or local setup because the work involves sensitive information or a particular control requirement. The decision depends on the data, the risk, the people involved, and what can be maintained responsibly.

The point is to make the choice visible. If nobody can explain the information path, then nobody can responsibly claim that the workflow is safe.

This episode is a conversation starter, not legal, cybersecurity, financial, or platform-specific advice. Provider policies change. Device settings change. Laws and contracts change. Read the current terms that apply to your own account and get qualified advice when the work carries real consequences.

Give AI a goal, not your judgment

AI works best when it has context. A vague request produces a vague answer. If you want useful help, explain the problem you are trying to solve, the person you serve, the constraints you have, and the result that would make the work better.

That does not mean treating a model as an authority that should decide what matters. It means treating it as a capable collaborator. You can tell a system, "Here is the outcome I need," and invite it to show possible routes. You can ask it to challenge assumptions, identify missing steps, propose a delivery plan, or compare a few approaches. Then a human still decides what is true, what fits the customer, what should be approved, and what should never be sent.

This distinction matters because fluent language is not proof. A system can write a clean paragraph, suggest a polished workflow, or sound extremely confident while missing the detail that matters most. The operator still has to ask: Does this match the evidence? Does it fit this customer? What would failure look like? What action can this system take without someone looking at it first?

AI can accelerate thinking. It cannot take responsibility for the outcome.

Start with a real business problem

The best AI project usually begins with a boring, specific problem. A lead comes in after hours and nobody responds. A customer asks the same question repeatedly. A team has a useful PDF but no reliable way to deliver it when someone texts or sends a direct message. A professional has years of hard-earned knowledge but no clear lesson plan that turns it into something another person can use.

Those are better starting points than "we need an agent" or "we need AI because everybody else has it." The technology should serve the workflow, not become the workflow's new boss.

Take a mobile detail business as an example. The owner may have a good service, a solid reputation, and a real demand problem. The bottleneck might be missed messages, uncertain quoting, slow follow-up, or customers who never get a clear next step. Before building a complicated AI system, map what happens from the first message to the booked job.

Where does the customer enter? What information is actually needed? Who owns the next action? What needs a human decision? What can be handled by a stable rule? What should be delivered automatically? What needs to be logged so a mistake can be fixed?

Only after those answers are clear is it useful to ask which technology belongs in the process.

A switch is not an agent

There is a lot of language in the AI world that makes simple things sound more complicated than they are. A fixed automation may be enough.

If a person sends a keyword by text message, the system can deliver a requested PDF. If a lead fills out a form, the system can send a confirmation, create a task, and alert the right person. If an appointment is missed, the system can place the customer in a follow-up queue. These are valuable systems. They do not need to make open-ended decisions to be useful.

An AI-assisted system can help when the work involves interpreting a request, drafting a first response, sorting unstructured information, or proposing options. But more flexibility also brings more ways to get it wrong. A system that can touch a customer record, send a message, change an appointment, or make a promise needs written boundaries.

Use the smallest reliable tool that fixes the actual leak. A dependable switch can beat a flashy agent when the job is predictable. An agent may be appropriate when interpretation truly matters, but it should begin with limited permissions, clear logs, human approval points, and an easy off switch.

That is not resistance to progress. That is what professional use looks like.

Turn experience into an offer

One of the biggest opportunities in this moment belongs to people who have been working for a long time. They have seen real failure modes. They know what customers actually ask. They understand where a handoff breaks down, where a person gets confused, and which shortcut creates a mess later.

That experience can become a lesson, a checklist, a process, a service, a training program, a template, or a system. AI can help organize it, test its wording, create supporting materials, generate a first draft of a curriculum, and explore delivery options. But the valuable part is still the experience itself.

In the episode, I use real estate education as one example. Someone may want to build a practical lesson plan that helps experienced agents understand where artificial intelligence can help with their workflows. The practical answer is not that AI must be in every step. Some steps are simply automation triggers, such as an if-this-then-that rule. Others might benefit from an AI assistant. The goal is to teach people to recognize the difference.

That same approach applies to any field. A former manager can turn a field-tested onboarding process into a training resource. A contractor can turn recurring client questions into a useful guide. A service business owner can create a follow-up system that protects response time. The raw material is the problem you understand better than a generic chatbot does.

The provider question is real

People reasonably ask what happens when they share an idea with a large AI provider. Could the provider learn from it? Could someone else build something similar? Could the platform change its rules, pricing, access, or feature set after a business begins to depend on it?

Those are legitimate questions. They should be handled with evidence and specifics, not with blanket accusations. Providers have different terms, different plans, different controls, and changing policies. A small-business idea can also be copied without AI. The important task is to decide what information is sensitive enough to require a different process and then set the boundaries before the work begins.

For some projects, the right move is to keep sensitive details out of a general consumer interface. For others, a business agreement, proper permissions, a redacted data set, or a local tool may be enough. For still others, the value of moving quickly with a mainstream model outweighs the risk after a deliberate review. There is no one answer that fits every organization.

What should not happen is accidental dependence. If a tool becomes central to revenue, customer communication, or proprietary knowledge, document the workflow. Know how to export the important data. Keep the human relationship with the customer. Have a way to work if the provider changes terms or the service is unavailable.

Build a record of what the system is allowed to do

The fastest way to lose control of an AI project is to leave the rules inside somebody's head. A business owner might understand that a tool is only supposed to draft replies. The person who connects the tool may assume it can send them. The employee receiving the draft may assume the tool checked the facts. The customer may hear a confident answer and believe a human approved it. By the time a mistake is visible, the system has moved across several people and no one can identify the decision point.

Write down the operating rule before the workflow becomes complicated. It can be simple. What enters the system? What information is allowed? What output is expected? What action can happen automatically? What must be approved by a person? Where is the record of that action? Who can stop the workflow? What does the team do when the answer is unclear?

This is especially important when an AI tool touches money, customer commitments, personal information, legal questions, health information, scheduling, public posts, or a company's reputation. The system may be able to draft faster than a human. That is not permission to send without a review.

A written operating rule also makes the project easier to improve. When something goes wrong, the team can tell whether the problem was the model, the input, the permissions, the handoff, the integration, or the assumption made by the person who designed it. Without that record, every failure gets blamed on "AI" and nothing useful gets fixed.

Test the boring cases before the hard ones arrive

Most demonstrations are built around a clean prompt and a cooperative user. Real customers and real work do not behave that way. People misspell names. They ask two questions at once. They change their minds. They send a message at midnight. They upload the wrong document. They ask for something the business does not offer. They are frustrated, impatient, or unclear.

Before giving an automated workflow access to the public, test it against ordinary messy situations. What happens if the required information is missing? What does it do when it cannot tell which service a customer wants? Does it invent an answer, or does it escalate to a person? If it sees something sensitive, does it repeat that information in the wrong channel? If an integration fails, does the customer receive silence, a confusing message, or a clear next step?

The goal is not to prove a system perfect. The goal is to understand the failure path before it affects someone who trusted you. This kind of testing is also where small businesses can move quickly. They can test one bounded workflow, improve it, and keep the improvement close to the person who feels the customer impact.

AI should earn more responsibility over time. Start with low-risk work, review what it produces, and expand only when the evidence supports it. A useful system is not the one with the most features. It is the one that does a defined job reliably, makes the human team stronger, and does not create a new mess for someone else to clean up.

The model landscape will keep changing

The competitive AI landscape changes quickly. In the episode I mention models and companies that are important to the current conversation, including ChatGPT, Claude, Gemini, open-source systems, and NVIDIA's NemoTron. The names and rankings will change. What matters more for a working business is the job.

Can the system produce a reliable first draft? Can it handle the type of information you have? Can it be used with the controls you need? Can the team understand and maintain the workflow? What does it cost after the novelty wears off? Where does it fail? How quickly can a person step in?

Choosing a model should resemble choosing any other important business service. Test it on a bounded job. Compare the result with a human baseline. Keep records of failures. Avoid building a critical customer experience around a feature you have never watched fail.

The right tool today may not be the right tool a year from now. That is another reason to build systems around the business outcome rather than around a provider name.

Think of AI as a utility, but do not surrender the wheel

My hope is that AI becomes more like a utility for ordinary builders. The point is not to create a world where only the wealthiest companies can use capable technology. A person with an idea, work ethic, and real experience should be able to create useful systems, communicate more clearly, and reach people without needing a giant team.

That possibility is exciting. It can help a single operator take on work that once required several specialists. It can help a small business respond faster. It can help someone turn knowledge into a structured resource. It can reduce repetitive work and leave more room for human attention where it matters.

But access to leverage is not the same thing as wisdom. The most capable system in the room should not automatically be allowed to make the biggest decision. Human beings still own the promises made to customers, the permissions granted to software, the data shared with providers, and the consequences of a bad workflow.

Use the utility. Keep the judgment.

A practical first-week plan

If you want to do something useful with AI this week, do not begin by buying five tools. Begin with a simple audit.

1. Choose one process that creates revenue, service, or customer trust.
2. Follow the last ten real examples through that process.
3. Write down where the work slows down, becomes unclear, or loses an owner.
4. Define the smallest outcome that would be an improvement.
5. Decide whether the first fix is a written rule, a basic automation, an AI-assisted draft, or a limited agent.
6. Set the privacy and approval boundaries before connecting data or customers.
7. Test the system on a small set of real but safely handled examples.
8. Keep a human review point until the results are consistently useful.

This process does not promise instant transformation. It does give you a way to move from AI conversation to AI work. It also makes it easier to recognize when a system is creating more complexity than value.

Keep a short scorecard as you test. Did response time improve? Did fewer inquiries get lost? Did the customer receive a clearer next step? Did the team save time without creating extra review work? Did the system make an error that a person caught before it mattered? These are better measures than whether the tool sounded impressive in a demonstration. They also give you evidence for the next decision: keep it, change it, narrow it, or turn it off.

The better question

It is easy to ask, "What is AI going to do to me?" Some of that concern is warranted. Technology changes jobs, expectations, privacy, attention, and the distribution of power. Pretending otherwise would not help anybody.

But there is another question worth asking alongside it: "What can I build with this, while keeping my values and judgment intact?"

That is the question behind this episode. If you are experienced, tired of waiting for a traditional safety net, curious about what is possible, or sitting on a real business problem that nobody has solved well, there may be something valuable to build next.

Watch the full conversation above. Then look at one real workflow, one real customer question, or one real point of friction. Do not try to solve the entire future in a single prompt. Build the first useful thing.

If you want to talk through the problem, the workflow, or the opportunity, you can book a conversation with Connor.

Common questions

Connor T. MacIvor · CalDRE #01238257 · Sync Brokerage, Inc. · DRE #02031490