1,000+ Hours of Using Agentic Assistants in 10 Minutes

May 31, 2026

1,000+ Hours of Using Agentic Assistants in 10 Minutes thumbnail

This is the compressed version of what I would tell someone after spending 1,000+ hours using agentic assistants.

Most discussions about AI tools get stuck in the wrong place.

People compare token prices, worry about whether the company will pay, or dismiss the whole thing because models sometimes hallucinate. Those concerns are not fake, but they are often not the highest-leverage questions.

The better question is:

Does this tool help me produce better work, faster, with enough reliability that the return is obviously larger than the cost?

For knowledge work, engineering, automation, research, writing, and internal process improvement, that is usually the right frame. Not “How do I spend the least?” but “How do I create the most useful output per hour?”

1. Think in ROI, not token price

If an AI tool saves meaningful time, improves the quality of your decisions, or helps you solve problems you would otherwise avoid, the monthly subscription price is usually not the main variable.

The mistake is treating AI like a small software expense instead of a productivity multiplier.

A better mental model:

  • If a tool helps you produce more value than it costs, use it more.
  • If a better model costs more but gives better answers, fewer dead ends, or faster execution, the more expensive option may be cheaper in practice.
  • If you spend hours optimizing token usage while losing focus on the actual work, you are optimizing the wrong layer.

This does not mean cost never matters. At company scale, waste compounds. If hundreds of people or automated workflows call models all day, usage discipline matters. But the first-order question is still value created. Cost optimization should come after you understand which workflows are actually valuable.

2. Do not let internal budget friction stop you

Another common blocker is bureaucratic friction.

Maybe the company has a budget, but getting approval is annoying. Maybe the process is unclear. Maybe nobody knows which tool is allowed. Then people either avoid using AI entirely or complain that they would use it “if the company paid for it.”

That is often a bad trade.

If a tool helps you learn faster, build better artifacts, make better decisions, or become more effective in your role, it can be worth paying personally while you figure out the company path. The career upside can be much larger than the subscription price.

At the same time, AI can help with the bureaucracy itself. Instead of only using AI for coding or writing, use it to remove administrative friction:

  • Draft the approval request.
  • Summarize the business case.
  • Compare options.
  • Prepare security or procurement answers.
  • Turn vague internal rules into a concrete checklist.

The meta-skill is not only “use AI to do the task.” It is “use AI to remove whatever blocks the task.”

3. Hallucinations are real, but they are not a reason to avoid AI

A weak way to use AI is to ask it for unsupported facts and then blindly trust the answer.

A stronger way is to use AI as a context engine: a tool that helps you retrieve, compare, organize, and reason over evidence.

For example, instead of asking:

What is the correct answer?

Ask:

Search the relevant documentation, quote the exact lines, compare the options, and tell me what is supported versus uncertain.

Or in engineering work:

Look at the code path, logs, error message, and tests. Separate what the repository proves from what you are inferring.

The point is to anchor the model to something verifiable:

  • official documentation
  • source code
  • logs
  • pull request comments
  • tickets
  • internal docs
  • screenshots
  • command output
  • real user requirements

When the model is grounded in concrete context, hallucination risk goes down and usefulness goes up.

4. Ask for evidence, not confidence

A model can sound confident and still be wrong. So I try not to ask for confidence as a feeling. I ask for evidence.

Useful prompts include:

What exact source supports this?
Which part is confirmed, and which part is your inference?
Give me the smallest next step to verify this locally.
Do not invent APIs, flags, or settings. If you are unsure, say so and search or inspect the actual file.

This is especially important for technical work. A hallucinated CLI flag, config key, library behavior, or deployment step wastes time and destroys trust. The model should be forced to ground its claim in the actual environment whenever possible.

5. Describe the outcome, not your assumed solution

One of the most valuable uses of AI is not answering your exact question. It is helping you escape a bad framing.

A common mistake is to ask about the solution you already imagined:

Which vertical MacBook sleeve should I buy?

That may be useful, but it might also be too narrow. A better prompt describes the real problem:

I want to pull my laptop out of my backpack quickly without removing the whole case. I also want to protect it during transport. What product categories or setups solve this problem?

The difference matters.

When you only ask about your assumed solution, AI optimizes inside your assumptions. When you describe the pain point and desired end state, AI can propose options you did not know existed.

This pattern applies broadly:

  • Do not ask only for the specific tool you imagined.
  • Explain what is annoying right now.
  • Explain what “solved” would look like.
  • Let AI map the bridge between the two.

That is how you get unexpected but practical solutions.

6. Use reverse prompting

AI should not only answer. It should challenge the premise.

A useful instruction is:

Before answering, ask whether I am solving the right problem. If there is a better framing, point it out.

This turns the model from a passive executor into a thought partner. It can ask:

  • Why do you want this specific solution?
  • What is the real bottleneck?
  • Is there a cheaper or simpler workaround?
  • Are you optimizing a small cost while ignoring a large time sink?
  • What would have to be true for this plan to be worth it?

The key is balance. Sometimes you want reflection. Sometimes you want execution. But for ambiguous problems, adding a reflective layer is extremely valuable.

7. Let AI broaden the search space, then verify

The ideal workflow is not pure creativity and not pure verification. It is both.

First, let AI broaden the solution space:

Here is my situation, here are the constraints, here is what I want. What are the possible approaches I am not seeing?

Then narrow it down:

Which of these are realistic for my situation? What are the trade-offs? What should I try first?

Then verify:

Check the official source, product page, repository, documentation, or local file before claiming this works.

This keeps the upside of AI creativity without blindly trusting unsupported output.

8. The practical operating principle

My current principle is simple:

Use AI aggressively where it increases output, but force it to stay grounded where correctness matters.

That means:

  • I do not obsess over small token savings when the real prize is better work.
  • I do not avoid AI because hallucinations exist.
  • I do not trust unsupported claims when the cost of being wrong is high.
  • I describe problems and outcomes instead of only asking about my assumed solution.
  • I use AI to challenge my framing, not just execute my first idea.

The goal is not to make AI cheap. The goal is to make work higher leverage.

Cost matters. Reliability matters. But both should serve the bigger question: does this help me create more useful output with less friction?

That is the frame that makes AI tools worth using seriously.