It only ever sees what your role allows.
An operational assistant is only safe if it inherits your permissions instead of the database's. Wingman runs real tools against your own schedule, fleet, training records and books — and the set of tools it can even consider is decided by who is asking.
Gated twice, on purpose.
The model is only shown what you may use
Before a single token is spent, the tool list is filtered by your role. A tool whose required capabilities your role doesn't hold is never offered to the model, so it cannot be called by accident or by suggestion.
The call is checked again at execution
Filtering the menu is not the security boundary. When a tool is invoked, every capability it declares is re-checked against your role, and a call that fails comes back as permission denied.
The same capabilities as everything else
Those capabilities aren't a separate AI permission model. They're the same scopes the rest of WingWrangler enforces on the same actions, so the assistant cannot become a side door around your roles.
> which 172s are due for a 100hr this week?
It answers by looking, and acts by doing.
Wingman doesn't summarise a knowledge base. It calls the same services your console calls, which is why the answer matches the board. Tools are registered as one of two kinds.
- check_schedule
What's on the board, for whom, in what.
- list_available_aircraft
Which tails are actually free and airworthy.
- get_aircraft_status
Where one airplane stands right now.
- get_weather
Conditions for the field.
- get_metar_taf
The raw METAR and TAF.
- check_student_progress
Where a student is against the syllabus.
- get_my_logbook
Your own hours and entries.
- get_account_balance
What's owed on an account.
- list_upcoming_maintenance
What's coming due, and when.
- get_active_squawks
What's open across the fleet.
- check_notifications
What's waiting for you.
- book_aircraft
Take a slot — through the same conflict checks a human booking goes through.
- cancel_booking
Release a slot, with the same cancellation policy applied.
- report_squawk
Log a discrepancy against a tail.
- log_flight
Write a logbook entry.
- send_message
Post into a thread you're already part of.
The thread is yours, and it persists.
Conversations are stored per organisation and per user, with every message kept — including the tool calls Wingman made and what came back. You can go back and see what it did, not just what it said. Old conversations archive rather than vanish.
Not welded to one vendor.
The provider is configuration. Which means a model deprecation is a config change, not a rewrite.
- Claude
- OpenAI
- DeepSeek
- Fireworks
The assistant is only as good as the record underneath it.
Booking through Wingman goes through the same conflict checks as booking by hand.
MaintenanceOpen squawks and upcoming inspections, asked in plain English.
TrainingStudent progress against the syllabus, and your own logbook.
ChatWingman can post into a thread — the same threads your people already read.
Can Wingman see data the person asking isn't allowed to see?
No. The tool list handed to the model is filtered by the asking user's role, and every tool re-checks its required capabilities at execution time. Those are the same capabilities the rest of the platform enforces, so the assistant has no privileges of its own.
Does Wingman only answer questions, or can it do things?
Both. Tools are registered as either query or action. Query tools read from schedule, fleet, training, billing and notifications. Action tools book and cancel bookings, report a squawk, log a flight, and send a message — each still subject to the role check.
Which model does it use?
It is provider-configurable rather than tied to one vendor: Claude, OpenAI, DeepSeek and Fireworks are all supported, plus a deterministic zero-token provider used for testing.