#how to steer main agent

1 messages · Page 1 of 1 (latest)

rapid nimbus
#

how to steer main agent, without sub-agents.

round lionBOT
#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> âś… Mark Solution

tawdry nacelleBOT
#

Use top-level /steer, not /subagents steer.

Example:

/steer prefer the smaller patch and don't touch unrelated files

or the alias:

/tell summarize before making the next tool call

That targets the current session’s active main run only. It won’t start a new run if the agent is idle, and it doesn’t pick a sub-agent. The guidance is injected at the next supported runtime boundary, so it may wait until the current tool call finishes.

Related but different: /queue steer changes how future normal messages behave while a run is active. /steer <message> is the explicit “steer this active run right now” command.

Docs: https://docs.openclaw.ai/tools/steer and https://docs.openclaw.ai/concepts/queue-steering

rapid nimbus
#

and how do I get the AI to send me back images via telegram, is that possible?

tawdry nacelleBOT
#

Yep, that’s possible.

The two normal paths are:

  1. You’re chatting with the agent in Telegram
    Ask it to generate/fetch/create the image, and have it send the result as media. OpenClaw supports outbound media by putting this in the assistant’s final text on its own line:
MEDIA:/path/to/image.png

or:

MEDIA:https://example.com/image.png

OpenClaw strips that line and sends the file/image as a Telegram attachment.

  1. You want to send to Telegram from somewhere else, like Discord
    Use the message send path with Telegram as the channel/target, e.g. CLI:
#
openclaw message send --channel telegram --target 123456789 --message "Here you go" --media /path/to/file.png

If an agent run originating in Discord needs to send to Telegram directly, cross-provider messaging may be blocked by default; enable tools.message.crossContext.allowAcrossProviders if you intentionally want that.

Things to check:

  • Telegram channel is configured and the recipient is allowed/pairing-approved.
  • The image file is somewhere OpenClaw is allowed to read.
  • channels.telegram.actions.sendMessage isn’t disabled.
  • Telegram media size stays under channels.telegram.mediaMaxMb — default is 100 MB.
  • If you want generated images, configure/enable an image generation provider/tool, then the agent can generate and return the resulting MEDIA: file.

Docs: https://docs.openclaw.ai/start/openclaw#media-in-and-out and https://docs.openclaw.ai/channels/telegram

rapid nimbus
#

does the AI already know how to send media?

tawdry nacelleBOT
#

Yes — the agent is told about the MEDIA:<path-or-url> convention in its runtime instructions, so it can already send media if the channel/tooling allows it and the file is readable.

For Telegram specifically: if the agent replies with a line like this on its own line:

MEDIA:/home/me/pictures/result.png

OpenClaw should extract it and send it as an attachment instead of showing the literal line.

If it doesn’t work, it’s usually one of these:

  • the Telegram channel isn’t configured/paired/allowed
  • outbound sends are disabled via channels.telegram.actions.sendMessage=false
  • the image path is outside what OpenClaw is allowed to read
  • the file is too large / unsupported
  • the agent generated a file but forgot to include the MEDIA: line

So: yes, it knows the mechanism; you may still need to tell it explicitly: “send the generated image back as a Telegram attachment using MEDIA:.”

rapid nimbus
#

Can I tell AI to handle bookings, and even order me food with my credit card and house location?

tawdry nacelleBOT
#

Yes, but I’d split that into safe autonomy vs final-purchase authority.

Good pattern:

  • Let the agent search options, compare prices/times, fill forms, and prepare a booking/order.
  • Require a human confirmation before anything that spends money, shares your address, books a slot, cancels something, or changes an account.
  • Use a dedicated card/virtual card with limits if you want it to pay.
  • Put clear standing orders in AGENTS.md: budget limits, allowed vendors, delivery address rules, allergies/preferences, and “stop and ask if unsure.”

I would not give a general-purpose agent raw, reusable credit card details and broad permission to buy anything. Too much can go wrong: prompt injection on websites, wrong address/item/date, hidden fees, account lockouts, etc.

A reasonable food-order rule would be something like:

Food orders: Agent may browse menus and prepare checkout. It must ask me to confirm restaurant, items, total price incl. fees/tip, delivery address, and ETA before placing the order. Never reveal or store card details in chat. Max spend: $35 unless approved.

For bookings, same idea: it can prepare and hold the slot if possible, but final submit needs your OK.

rapid nimbus
#

so can it book, purchase, and order for me?

tawdry nacelleBOT
#

Yes — technically it can, if you give it the right tools/access:

  • Book appointments/tables/travel slots via browser automation or APIs
  • Purchase/order items or food through websites/apps that work in the browser
  • Use saved logins/payment methods if the browser/profile has them
  • Send you confirmation/screenshots/receipts afterward

But the safe setup is: agent prepares, human confirms, then it submits.

For anything involving money, legal commitments, your home address, or cancellations, I’d keep a hard approval gate:

The agent may fill carts and booking forms, but must ask for confirmation before final submit/payment. It must show vendor, items/service, date/time, total cost incl. fees/tip, delivery/address used, and cancellation/refund policy if relevant.

If you want more autonomy later, use narrow standing orders: trusted vendors only, max spend, approved address, virtual card/limited card, and exact “stop and ask” rules.

#

So: yes, it can do the workflow. Don’t give it unlimited purchase authority on day one. 🦞

rapid nimbus
#

How will I give it my credit card or house address information? And if I do, won't OpenAI or the Model Provider know my location now, should I also use Signal when giving information?

tawdry nacelleBOT
#

Don’t give credit-card or home-address info in this Discord thread. This is exactly the kind of thing to keep out of public/support chats.

Safer ways to do it:

  • Credit card: don’t store raw card numbers in OpenClaw memory or chat. Use a browser profile where the card is already saved, Apple/Google Pay, merchant-saved payment, or a virtual card with a low limit. Let the agent get to checkout, then you approve the final submit/payment.
  • Home address: put it only in a private local place if needed, or better: save it in the merchant account/browser autofill and have the agent select it. Still require confirmation before ordering.
  • Best rule: agent may prepare carts/bookings, but must show you vendor, items, total, address, ETA/date, and ask before paying/submitting.

On privacy: yes, if you type your address/card details into a conversation that uses a cloud model, the model provider may receive that text as part of the prompt/context. Signal can protect the message in transit to your gateway, but it does not hide the content from the model provider once OpenClaw sends it to the model.

If you want maximum privacy, use:

  • local/browser-saved payment instead of telling the model the card number
  • virtual/limited cards
  • local models where practical, or a provider/account you trust
  • strict approval gates for purchases

So: Signal is better than Discord for private transport, but it is not a magic privacy shield from OpenAI/Anthropic/etc. if you’re using their cloud model.

rapid nimbus
#

Should I give openclaw a tool for when paying, it uses the tool and gives money from my main card to virtual card, and then the virtual card to pay for whatever?

tawdry nacelleBOT
#

I wouldn’t build it as “agent can move money from my main card whenever it wants.” That’s too much authority in one place.

Better design:

  • Use a virtual card provider that supports spend limits per merchant/order/day.
  • Keep the funding/top-up step human-approved, not autonomous.
  • Give OpenClaw a narrow “payment helper” tool that can do things like:
    • create a virtual card for a specific merchant
    • set max amount, expiration, merchant lock
    • return only the last 4 digits / payment token if possible
    • never expose your main card number
  • Require confirmation before both:
    1. creating/loading the virtual card, and
    2. submitting the actual purchase

A safe flow would be:

#
Agent prepares order → shows total/address/vendor → asks approval → creates virtual card capped at $X for that merchant → fills payment → asks final approval → submits order

Guardrails I’d want:

  • max spend per transaction/day/week
  • merchant allowlist
  • no cash-like purchases, gift cards, crypto, money transfer, or subscriptions without explicit approval
  • virtual card expires quickly
  • transaction notifications to you
  • logs/receipts saved
  • easy kill switch / revoke card

So yes, a virtual-card tool is a good idea — but make it cap-limited and approval-gated, not “agent refills from main card and pays for whatever.”

rapid nimbus
#

what about booking airplane tickets, can I do that safely, to get me the best airplane ticket for most privacy but still affordable and cheap

tawdry nacelleBOT
#

Yes, but flight booking is one of the places where I’d be extra conservative.

Good safe workflow:

  1. Agent researches only
    It can compare flights across Google Flights/Kayak/airline sites, optimize for price, layovers, baggage, refundability, arrival time, etc.

  2. Agent gives you a shortlist
    For each option: airline, route, times, baggage rules, refund/change rules, total price, booking site, privacy tradeoffs.

  3. You choose
    The agent should not decide “best” silently unless your criteria are very explicit.

  4. Agent fills checkout, but does not submit
    It may fill passenger info/payment from browser autofill or saved airline profile, then stop at the final confirmation page.

  5. Human approval before purchase

#

Before buying, it should show: exact passenger name, dates, airports, fare class, baggage, seat fees, total price, cancellation/refund policy, and payment method last 4.

For privacy + affordability:

  • Prefer booking directly with the airline when the price is close. Less third-party data sharing, fewer support nightmares.
  • Use a dedicated email/phone alias for travel if you want privacy.
  • Use a virtual card with a per-purchase limit.
  • Don’t let the agent store passport/known traveler/payment details in chat memory. Use browser/airline profile autofill instead.
  • Avoid sketchy ultra-cheap OTAs unless the savings are worth the support/privacy risk.
  • For international flights, be careful: passport/DOB/legal name are unavoidable for ticketing.

A good standing order would be:

Flights: Agent may research and prepare booking only. It must ask before purchase. Prefer direct airline booking if within $30 of cheapest reputable option. Never book basic economy unless explicitly approved. Show total price, baggage, refund/change rules, passenger details, airports/dates, and payment last 4 before final submit.

So: yes, safely, if the agent is your researcher/checkout assistant — not an unsupervised travel agent with your card.

rapid nimbus
#

should I give openclaw a mini car with hands and can grab things and etc?

tawdry nacelleBOT
#

Eventually? Extremely cool. Today? I’d start much smaller and safer.

A mini car with grippers is basically giving the agent physical-world authority, so treat it like a power tool, not a toy.

Good progression:

  1. Observe-only first
    Camera feed, object detection, “tell me what you see,” no movement.

  2. Movement sandbox
    Let it drive only in a clear test area, slow speed, no stairs, pets, people, glass, cables, or valuables.

  3. Human-confirmed actions
    Agent can propose: “I think I should pick up the red block.” You approve before it moves/grabs.

  4. Hard safety limits
    Physical kill switch, speed limit, geofence, max grip force, collision sensors, emergency stop, battery/fire safety, logs.

#
  1. No risky tasks
    No knives, hot drinks, medicines, doors/locks, pets, fragile items, stairs, or anything near people until you’ve tested a lot.

So my honest recommendation: yes as a research/project robot, no as an unsupervised household helper yet. Start with a rover that can look around and maybe push foam blocks. Add hands/grippers only after the motion safety is boringly reliable. 🦞

rapid nimbus
#

is it best building my own mini car for project, or buying one and just using it with openclaw with some setup as a project? I prefer buying.

and how do I get AI to control my phone calls for free, Anything with a rate limit of 20 calls per day is fine for me for receiving, not making calls but answering and talking to people.

I want it to be able to respond to calls and handle it like how I would, and if they need something the AI would text me and I would text it back and it would tell the caller, and the AI would know the name of the caller where I can provide how to respond and it should have tools to forward call to call (where I talk on the phone for emergencies or specific scenarios or for a specific caller) or end call and prioritize forward call to text, and it should also be able to ignore a caller.

I want it to use my phone number as well. So, how?

tawdry nacelleBOT
#

For the mini car: since you prefer buying, buy a kit. Don’t build the chassis/electronics from scratch unless the project is robotics itself.

What I’d look for:

  • Raspberry Pi / ESP32 / Arduino based, not cloud-only
  • documented local control API: HTTP, MQTT, Python, ROS/ROS2, serial, etc.
  • camera support
  • low-speed mode + physical power switch
  • simple gripper optional, but start with driving/camera first
  • can run on your LAN without vendor servers

Then connect it to OpenClaw with a tiny local tool/API: move_forward, turn_left, stop, camera_snapshot, maybe grab/release later. Keep it observe-only at first, then human-approved movement, then limited autonomy. Physical robots need boring safety rails. 🦞

For phone calls: yes, OpenClaw has a Voice Call plugin, but the “free + my existing phone number + AI answers live calls” part is the hard bit.

Reality check:

  • OpenClaw can do inbound/outbound voice via Twilio, Telnyx, or Plivo.
  • Those are not usually free. Even 20 calls/day will have phone-number/minute/provider/model/TTS/STT costs.
#
  • Your normal mobile number usually can’t be directly controlled by OpenClaw. iPhone/Android/carriers don’t generally let an app/agent answer PSTN calls and speak for you.
  • Signal/Telegram/WhatsApp are message channels; they don’t magically let OpenClaw answer your carrier phone calls.

Best practical setup:

  1. Get a telephony number from Twilio/Telnyx/Plivo, or port a number there.
  2. Configure OpenClaw voice-call plugin with inbound calls enabled.
  3. Forward your personal number to that provider number when you want AI screening.
    • unconditional forwarding, or
    • forward when busy/no-answer, depending on your carrier
  4. OpenClaw answers, talks to caller, summarizes/texts you on Telegram/Signal/Discord.
  5. If urgent, it can tell the caller “one moment” and notify you. True live transfer back to your mobile depends on provider support/config; the current OpenClaw plugin exposes call speak/end/continue/DTMF tools, while provider-level transfer/bridging may need custom work.

For your desired behavior, I’d design it like:

#
Phone assistant rules:
- Answer only allowed callers, or unknown callers with a screening script.
- Ask caller name and reason.
- Never claim to be me; say it is my assistant.
- If emergency/family/VIP: text me immediately and attempt transfer/escalation.
- If normal: collect message, confirm callback info, send me summary.
- If spam/sales: politely end call.
- If unsure: ask me by Telegram/Signal before making commitments.

Important privacy point: caller audio/transcripts may go to the voice model/STT/TTS providers you configure. If you want max privacy, use stricter caller allowlists, short retention/logging, and avoid giving the call agent broad tools.

Docs: https://docs.openclaw.ai/plugins/voice-call and https://docs.openclaw.ai/cli/voicecall