A command line utility must be created to manage tasks, modules and task groups. This includes everything from basic commands such as loading/unloading modules and signalling/killing/starting tasks or tasks groups, right up to the more advanced features such as changing task group membership, adjusting flow control elements on task groups and s on.

The command line utility should actually be implemented as a stdin/stdout/stderr interface to an admin command system built-in to mantra. Each module should be able to extend the commands usable by the admin command system.

An access control system should also be built into the admin control system, which should be optional. With this, each command should be able to have access controls assocated with it, and access to the current authenticated user's access information should be available to any module writer's admin extensions so they can regulate access to subcommands. Additionally, built-in commands and subcommands should be able to have their access control requirements altered programatically.

Access controls can be implemented by any number of mechanisms, either via. a full ACL style system, or simple group membership mechanisms. Additional controls should be available to do things like limit usage of certain commands during certain hours, from certain sources, etc.

Optionally, a built-in mechanism to support a telnet style interface (ie. binding to a port) should be provided for the user, and the user should easily be able to implement their own interface for access controls (interface via. another language, a secured interface, web-based interface, whatever). In all cases the command set should remain the same.

'Primary commands' (ie. the first word of any command) should be case insensitive. It is recommended that all sub-commands also be case insensitive, however this is up to the designer of the admin extensions.