Most AI tools start from a blank chat box. That is useful for asking questions, but it is not always where work happens. In a real workspace, a person is usually looking at a task, a meeting, a Helpdesk ticket, an email thread, a document, or a database row when they know what should happen next.
Aamu.app moves AI closer to that moment. Instead of treating AI as only a separate assistant, Aamu can read the current workspace context, understand a short instruction, and route it to a supported action. A comment like @ai Move this meeting to tomorrow at 13:00 should not produce a polite suggestion telling someone else to update the meeting. It should update the meeting.
That is the idea behind AI commands in Aamu: comments, chats, and the AI panel can become small command surfaces for the workspace itself.
From answer bot to action router
A plain AI answer is text. An AI command is text plus intent, context, validation, and a product action.
When a user writes a request, Aamu first decides what kind of request it is. Is the user asking for a general answer? A task draft? A reply draft? A meeting update? A database row change? That intent routing step matters because different requests need different safeguards.
For example, answering a question from Team Brain is not the same as changing the start time of a meeting. Drafting a Helpdesk reply is not the same as sending it. Creating a new task is not the same as editing an existing database row. Aamu's AI command layer keeps those cases separate.
The routing has two levels. First, an intent router recognizes common workspace actions such as creating a task, updating a Doc, changing a meeting, or editing the current database row. For the broader operation set, Aamu then selects a specific operation from the same OpenAPI-described surface used by the public Aamu API and builds arguments from that operation's schema.
This does not mean the internal AI needs an API key or makes an external HTTP request back into Aamu. The operation is executed inside Aamu with the signed-in user's session and project access, reusing the existing product handlers and server-side functions.
Ask Aamu for product help
Not every request should become a workspace action. In the Launch AI dialog, prefix a question with aamu: when you want to ask how Aamu.app works:
aamu: How do I share a Doc with a public link?This routes the question to Aamu's dedicated product-help assistant before the normal workspace action router. It searches Aamu's public documentation, returns supporting source links, and does not use the current team's Team Brain or modify workspace data.
Read more about Ask Aamu and the public Support API.
Where commands can start
The command does not have to start in one dedicated AI page. It can come from several places:
The AI panel, where the user asks Aamu to work with the current page. Use
aamu:when the request is product help rather than a workspace action.Comments with @ai, where a normal workspace discussion can include an instruction to AI.
Chat messages, where a team conversation can ask AI to create follow-up work or use the current chat as context.
Feature-specific AI buttons, such as Helpdesk triage and support reply drafting.
This is important because the right context is often already on the screen. A meeting page knows which meeting is being discussed. A database row knows which row and table are open. A Helpdesk ticket knows the customer conversation. A chat knows the recent messages.
What Aamu can do today
The current command set focuses on actions that fit naturally inside a team workspace.
Create task drafts from the current context, such as a support conversation, email, document, chat, or database row.
Update existing tasks when the task can be resolved from the current page or instruction.
Create and update Docs for internal knowledge and follow-up writing.
Draft or rewrite replies for Helpdesk tickets and email threads while keeping sending as a separate step.
Create email drafts for outbound communication.
Create meetings and update existing meetings.
Create and update Forms, define questions, publish the form, find existing forms, and submit database-backed responses.
Create and extend databases, add tables and columns, and create, update, query, or link database rows.
Manage database automations, including listing, creating, updating, and deleting automation definitions.
Use database GraphQL when an operation needs the generated schema for structured row queries or mutations.
Work with files, project users, contacts, Helpdesk, and Email operations that are available through Aamu's broader operation surface.
Search Docs when the user is asking for existing written knowledge.
The practical boundary is now close to the public Aamu API's operation set. The difference is authentication and context: an external integration uses an API key and explicit scopes, while the internal AI uses the signed-in user's workspace permissions and the page or conversation already open in Aamu.
How Aamu chooses an operation
A broad tool list is useful only if the assistant can select the right tool and fill it safely. Aamu uses a staged process:
The intent router separates a general answer from a concrete product action.
Established context-aware actions, such as task, Doc, meeting, reply, and current-row commands, keep their specialized handling.
Other product actions are matched to one OpenAPI operation, such as
createForm,updateForm,submitForm,addDatabaseColumns,createDatabaseAutomation, ordatabaseGraphQL.The selected operation's schema guides the path parameters, query parameters, and request body.
The normal server-side validation and product handler execute the action with the user's accessible projects.
Using the operation schema reduces guesswork, but it does not remove product safeguards. If an id, project, database, required field, or permission is missing, the underlying handler rejects the operation instead of allowing the model to bypass validation.
Example: creating a Form from the AI panel
A user can ask:
Create a Form called Contact Form that asks for a name and email address.
Aamu maps that request to the Forms API createForm operation. The operation schema tells the AI that the request needs a name and a list of typed fields. Aamu creates the Form in the selected project and opens it in the Form editor, where the user can review it, add more questions, or publish it.
The same operation is available to external integrations through POST /api/v1/forms/. Internal AI uses the signed-in user's access instead of an API key, but both paths share the same validation and Form creation behavior.
Example: rescheduling a meeting from a comment
A meeting comment might say:
@ai Move this meeting to tomorrow at 13:00
A text-only assistant might reply, "Sure, update the meeting to tomorrow at 13:00." That is not enough. The user already knew what they wanted. The useful action is to change the meeting.
For this to work well, Aamu has to pass the right context into the command:
the source type is a meeting, not just a generic page;
the existing meeting id, title, start time, end time, and invitees are available;
the user's timezone and browser offset are included, so "tomorrow at 13:00" is interpreted as the user's local time;
the command result updates the meeting instead of only writing another comment.
That last point is the product difference. The AI is not only writing about the workspace. It is using the same workspace model that the UI uses.
Why timezone details matter
Time commands are deceptively hard. "Tomorrow at 13:00" is clear to a human because the human silently applies local time. A server does not know that unless the client or user profile tells it.
Aamu sends both the user's timezone name and the browser timezone offset with AI commands where time may be interpreted. The timezone name is useful as a stable user preference. The browser offset is useful because it reflects the user's current environment, including daylight saving time.
This matters for meeting updates, task dates, reminders, and any future command that turns natural language into a timestamp. Without it, a command can look correct in the AI reply while storing the wrong time.
Example: turning a conversation into a task
A common team pattern is that a conversation creates follow-up work. Someone explains a customer issue in a Helpdesk ticket, email thread, chat, or meeting note, and the next step is obvious: make a task for the team.
@ai Create a task to check why this customer cannot import contacts. Assign it to support and include the relevant details.
The useful task draft should not only contain the sentence the user typed. It should use the current context as source material: the ticket, email thread, chat, or row the user was looking at. It should produce a clear title, useful body, and link back to the original item when possible.
This is where Aamu's connected workspace helps. Tasks, Docs, Helpdesk, email, meetings, databases, and comments are already part of the same product, so AI does not have to operate from a disconnected browser extension or copied prompt.
Example: editing CRM data from the row itself
The new small-team CRM template is a good example of why AI commands become more useful when the data is structured.
A user might open a deal row and say:
@ai Move this deal to Proposal, set probability to 60%, and link the primary contact to Anna from Northwind.
That is not just a writing task. It is a database operation. Aamu needs to know the current row, the table columns, the available reference targets, and which fields are safe to change. The command router can then choose between updating the current row, creating a new row, or linking the current row to another row.
This is the direction where AI starts to feel less like an add-on and more like an editing layer for the workspace.
Human review still matters
Aamu's AI support features already follow a human-in-the-loop model. A generated Helpdesk or email reply is a draft until someone sends it. That principle still applies when commands become more action-oriented.
Not every command should be automatic, and not every action has the same risk. Creating a task draft is low risk. Sending a customer reply is higher risk. Updating a meeting time affects other people. Changing CRM data affects reporting and follow-up. A useful AI command system needs product boundaries, not only model confidence.
Aamu therefore requires explicit intent or confirmation for higher-risk operations such as sending messages, deleting an automation, or running a GraphQL mutation. Read operations and ordinary reversible workspace edits can remain more direct.
That is why Aamu separates intent routing, operation selection, argument planning, context gathering, validation, and execution. The AI can interpret the request, but the product still decides what actions exist and how they are applied.
How this fits with Team Brain
AI commands are not only about changing objects. Sometimes the right action is to answer from existing company knowledge or find the right internal Doc. That is where Aamu's AI support workflow and Team Brain connect to commands.
A command can use the current page as context and also retrieve related Docs or Team Brain material. That makes the result less generic. A support draft can use the latest policy. A task can include the relevant troubleshooting detail. A Doc update can reflect the source conversation instead of starting from memory.
The useful pattern is simple: workspace context tells AI what is happening now, and Team Brain tells AI what the team already knows.
Why comments are a natural command surface
Comments are already where teams say what should happen next. People write "can someone follow up?", "move this to next week", "turn this into a doc", or "connect this to the customer record" all day long.
Adding @ai to that flow makes the instruction explicit without moving the user into a separate automation builder. It also keeps the action visible in the same place as the discussion. The team can see that AI was asked to help, and the resulting task, meeting, draft, or row remains connected to the original work.
This is not a replacement for buttons, forms, or careful workflow design. It is a faster path for the cases where the user can describe the intended action more naturally than they can click through several screens.
The bottom line
The most useful AI inside a workspace is not only a chatbot. It is a context-aware layer that can help with the work already in front of the user.
In Aamu.app, AI commands connect natural language to the workspace operation surface: tasks, Docs, Forms, Helpdesk, Emails, meetings, files, databases, GraphQL rows, automations, users, and references. The command router decides what kind of request the user made. The operation schema describes what the selected action accepts. The current page gives context. Team Brain can add company knowledge. The signed-in user's access controls where the action can run.
That combination is the interesting part. AI can answer questions, but it can also help keep the workspace moving: update the meeting, submit the form, extend the database, create the automation, link the CRM row, draft the reply, and leave the team in control.