Should an AI assistant be one chat box or many pages?
A single conversation surface with modes is usually the better default. It keeps context with one agent and switches between building, research, trading and document work without losing the thread. Separate pages still have a place, but only for supervision, settings and public markets. The test is not visual; it is whether context must cross a boundary.
Why do most tool suites end up as a set of disconnected dashboards?
Dashboards multiply because each capability arrives as its own product with its own navigation, permissions and mental model. A chat box that cannot act gets a page for files, a page for billing, a page for integrations. The result is a set of tabs that each remember one slice of the work and forget the rest.
A single conversation surface can take the opposite approach. The same box can start a build, ask a market question and draft a document, then return to the build with the earlier context intact. GROX is built around this route-and-execute pattern rather than a page per capability.
| Task | Many dashboards | One conversation surface |
|---|---|---|
| Start a build | Open code page, re-describe project | Ask in the same thread, choose an engine and build |
| Check a market | Open analytics page, switch context | Ask in the same thread, receive analysis |
| Draft a document | Open documents page, start new file | Ask in the same thread, edit with earlier context |
| Follow up | Search each page for status | Ask for status across previous work |
Which operations still deserve a page of their own?
A page is better when the task is inspection, not action. The public marketplace where agents and workers are for hire is a browsing surface; it does not benefit from being hidden inside a thread. A hire is escrowed first, runs on the hired agent's side, is paid on completion and refunded in full if it fails, with a dispute window after. That state needs to be visible and reviewable.
Settings, billing and plan comparison are also pages. A person should not have to converse to change a key or read current prices. The split is simple: conversation for work that uses context, pages for state that must be supervised.
- Persistent memory
- History that survives between sessions, so a request can refer back to earlier work without re-explaining.
- Autopilot
- A routine that can be flipped on to run unattended after you set it.
- Overnight Engine
- The mechanism for pursuing objectives without a person watching the whole time.
- Circuit
- A reusable automation that can be shared and installed from a store.
What should happen when you switch modes mid-task?
Switching modes should feel like moving between tabs in one project, not logging into another product. The same box, same project and same memory should persist. A request to check a market while a build is open should return with enough context that the next code prompt can continue without a fresh brief.
The mode is only a routing decision: the surface sends the request to the right models, tools and data, then brings the result back to the same conversation. Nothing is lost because the thread is not stored in the mode; it is stored with the agent.
When is a simpler tool the better choice?
If a person only ever does one thing and never passes context between tasks, a single-purpose tool or a traditional dashboard may be the better choice. There is no reason to operate a universal surface for one repeated workflow that already has a clean page.
The case for one box strengthens when the same agent needs to answer an email, post the tweet, ship the code, sign the deal and run the trade without losing the thread between them. If that cross-task continuity is absent, simpler is fine.
What is the one rule for adding a feature without adding a page?
Make it a mode when it uses the same persistent context and returns to the same conversation. A new capability should be selectable inside the thread, not a new destination that stores its own state.
If it needs public browsing, supervised state or user-managed settings, it can stay a page. The rule stops dashboards from multiplying while still giving inspections a home.
Common questions
Do I lose context when I switch between tasks?
No. The assistant uses persistent memory between sessions, so the same agent keeps the thread. Switching from building to trading or document work does not require re-explaining the project. The earlier context remains available when you return to the previous mode.
Does a one-surface assistant replace specialised tools?
Not necessarily. It can act inside existing tools through connectors, but if a task is isolated and never shares context with other work, a simpler tool may be the better choice. The one-surface approach is most useful when tasks need to pass context back and forth.
What should not live inside the chat box?
Supervision of escrowed hires, the dispute window, settings, billing and the public marketplace are better as pages. They involve inspection, review or browsing rather than action inside a conversation. Pages should hold state that needs to be supervised without being hidden in a thread.
How does the assistant decide which model or tool to use?
It routes each request to the right models, tools and data. In GROX Code, you can choose which AI writes your code and see the credit price of each before you choose. Some engines run only on your own provider key when the platform holds no key for them.
For a single surface that keeps context across builds, markets and documents, see how GROX works or compare plans on the pricing page.