“Watch Bitcoin for me and speak an alert on my phone when it reaches my target.” A short request brings several capabilities together.
The model interprets and reasons. The agent organizes the task, uses tools and checks results. Skills supply reusable ways of doing the work. Price data, a running scheduler and phone speech turn the request into an operational service.
1. The model understands the request
A language model can interpret ordinary language, analyze information, generate text and, in a system that supports tool calls, propose the next operation.
“Tell me when Bitcoin reaches eighty thousand” leaves questions: USD or USDT? Which price source? What if the price already meets the target? Alert once, or keep watching? The model helps make those choices explicit.
A current price requires an actual data query. Training knowledge and numbers from an earlier conversation cannot establish the latest quote. Even when an AI product has internet access, a data tool supplies the price.
A reply saying “I will watch it” does not start an all-day background process. Continued work needs a running environment and an actual scheduled task.
2. The agent organizes the work
Here, an agent means a task-execution system built around a model. It combines the goal, context, tools and operating rules, and uses tool results to decide what to do next. A predetermined workflow can handle fixed steps too. Official explanation of agents and workflows ↗
For a price alert, the agent checks the plan, calls an available monitoring tool, saves the task and reports whether creation succeeded. If something fails, it should explain which step failed.
The model may request a price query; a tool makes the request. The model may suggest a check every minute; a server scheduler keeps time. The agent connects these parts.
3. Skills package a reusable method
A Skill contains task instructions and may include scripts, references and templates. A compatible agent loads the relevant material when needed. Agent Skills format ↗
A suitable price-monitoring Skill could specify how to fetch quotes, check timestamps, compare thresholds, prevent duplicate alerts and record errors. Scripts handle exact comparisons; instructions explain when to run them and how to interpret the result.
Installing a Skill does not install a new model or grant new account permissions. Execution still depends on available software, tools and authorization. An agent with complete monitoring tools may already handle this task without another Skill. Skills make a method easier to reuse and inspect.
4. Example: a Bitcoin price alert
The request below illustrates responsibilities. USD 80,000 is a fictional demonstration threshold, not a current quote or a trading recommendation. Actual task creation depends on the sources, monitoring rules and tools supported by the current workspace.
Monitor CoinGecko’s Bitcoin price in USD every 60 seconds for the next 24 hours. When one valid sample is below USD 80,000 and a later valid sample reaches or exceeds USD 80,000, send one spoken alert through MochiBot, then end the task. Use English speech. Show me the plan first. If the starting price already meets the target, ask whether I want an immediate alert. Do not place trades.
Check the plan first
The plan should identify the asset, source, quote currency, condition, interval, expiry, repetition rule and receiving phone. Show the exact expiry time and time zone, and explain any missing data integration before creating the task.
BTC/USD must not silently become an exchange’s BTC/USDT pair. Sources can quote different prices. CoinGecko’s price endpoint can return a price timestamp so software can check freshness. Price and timestamp documentation ↗
After checking the plan, follow the current alert flow and reply “Confirm.” Monitoring begins only after actual task creation succeeds and the enabled task can be found. A written plan is still a proposal.
The server performs the checks
At each scheduled check, software fetches a quote, validates its source, value and timestamp, then evaluates the rule. For example, valid samples of USD 79,980 followed by USD 80,020 satisfy this demonstration’s crossing condition.
Failed or stale data should produce an error and a retry, not a false trigger. A 60-second sample interval can miss a brief crossing between checks; it is not tick-by-tick monitoring.
Once this numeric rule is defined, code can fetch, compare and deduplicate results without asking a model again every minute. A request to explain the move using recent news adds research and model work, with different time and usage costs.
The phone receives and speaks
When the condition matches, the server creates an alert event and sends it through the configured channel. MochiBot then handles notification and speech according to the receiving switch, system permissions and phone state.
The model understands “tell me”; the phone’s speech capability actually says the words. Sending an event, receiving it on a phone and speaking it are separate results to verify.
5. Two different uses of “60 seconds”
The server’s price-check interval controls how often it samples a new quote. The phone’s receiving connection controls how an existing alert reaches the phone. These are separate parts of the system.
The current Android receiver uses a long poll that can wait for about 60 seconds. An event can make that request return earlier; every alert does not have to wait a full extra minute. Network conditions, background restrictions and phone state still affect delivery.
Long polling is a receiving method; it cannot bypass the phone system’s background restrictions. Check locked-screen reception and speech on your own phone before relying on it.
6. Self-hosting and hosted workspaces
The responsibilities stay the same; who maintains the runtime changes.
- Self-hosted server: you maintain uptime, updates, networking, data integrations and task execution. Use a configured cloud model API or a local model supported by the environment.
- Hosted workspace: the platform maintains the runtime; you use your own workspace and configure its model as required. A particular price source or rule must still be supported.
- MochiBot: a client for conversation, tasks, alert reception and phone speech. Another chat channel needs its own notification and speech capability check.
Server monitoring does not require leaving the conversation visible. Timely phone speech requires connectivity and permission to receive reminders. iPhone / iPad: In development.
7. How to know it is actually running
Look beyond a reassuring reply:
- A clear plan: source, currency, condition, repetition and expiry are explicit.
- An existing task: confirmation produces an enabled task with the status the system actually supports.
- Execution evidence: quote times, condition results or error reasons can be checked.
- A working delivery route: test an ordinary voice alert, then a condition trigger. Cancellation should stop subsequent checks or triggers.
The model lets you state a goal naturally. The agent connects capabilities. Skills preserve the method. Tools and runtime services perform the operations. Together, they can turn repeatedly opening a price app into a confirmed monitoring task that tells you when attention is needed.
Continue with MochiBot voice alerts: plans, confirmation, review and cancellation, or inspect the actual capabilities of individual packages in the Skills directory.