Platform Administration

1. Initial Configuration Order

After changing the administrator password:

1. Configure an actual model service and test connectivity.
2. Select that model for TimechoDB Operations Assistant.
3. In Execution Channels, confirm that the database connections created by operations staff are available. Set a separate password for each connection if needed.
4. Create users, bind database connections, and configure budgets and user groups as required.
5. Upload knowledge base materials, bind skills, and set access scopes for agents and knowledge bases.
6. Use a regular account to test a read-only query. Verify approvals on an isolated test object.

Also create a second administrator account for emergency unlocking and password resets.

2. Configure Models

A model understands questions and generates answers. It must connect to an actual model service.

1. Open Model Configuration → Add Configuration.
2. Select a model from the built-in catalog, or enter the Provider, Base URL, API Key, and model name supplied by the service provider.
3. Save → Connectivity Test → Set as Default after the test passes.
4. Open Agents → edit the assistant → select the Default Model → save.

Parameters: The provider is commonly openai-compatible; an example URL is https://llm.example.com/v1. Obtain actual values from your provider. Once saved, an API key is masked with only its last four characters visible.

Requirements:

• The initial demonstration model only demonstrates the workflow. Production use requires a real model that supports tool calling.
• Verify streaming and image understanding support in practice.
• Disabled models cannot be selected for new conversations.

Verification: Create a conversation and complete a query with the actual model. A connectivity test alone does not replace a complete question-and-answer check.

3. Create and Maintain Users

1. Open User Management → Create User.
2. Enter the username, display name, initial password, role, database Context, and daily budget.
3. Keep Require Password Change on First Sign-In enabled. After saving, provide the URL and initial credentials through your organization's approved channel.
4. Ask the user to sign in, change the password, and test a read-only query.

Operations staff must create the Context first; see Configure and Verify a TimechoDB Context. Users inherit the permissions of the database account in the Context bound to them. In production, non-administrators without a bound Context cannot execute SQL.

Task	Action and effect
Reset password	Requires a password change at next sign-in and immediately invalidates existing sign-in sessions; revoke existing API tokens separately
Unlock account	Unlock in User Management without waiting for the default 15-minute period
Disable account	Takes effect immediately; API tokens owned by the account also stop working
Adjust budget	Change the daily token budget; it controls usage and is not a strict spending cap
Change role or connection	Edit the user; you cannot change your own role or disable yourself, and the last enabled administrator cannot be demoted

4. Set Database Connection Passwords

When database accounts use different passwords, manage a separate password for each Context:

1. Open Execution Channels and find the Context under Database Connection Passwords.
2. Click Set Password and enter the actual database password.
3. The platform tests the database connection before saving. The saved password is no longer displayed.
4. Test a query with an account bound to that Context.

Maintenance:

Situation	Handling and effect
Target Changed is displayed	The host, port, nodes, or account may have changed. The platform stops using the previous managed password. Verify the new target and click Replace to set it again
Clear a managed password	The platform usually falls back to the shared deployment password. If shared-password fallback is disabled, database operations through this Context become unavailable

Audit: Setting, replacing, and clearing passwords create audit records without recording the password itself.

5. Manage User Groups and Access Scopes

User groups assign access to agents or knowledge bases in batches. They do not replace database account permissions.

1. Open User Management → User Groups at the bottom of the page. Create a group and select members.
2. Edit an agent or knowledge base and select the required groups under Access Scope.
3. Test visibility and usage with accounts inside and outside the group.

Authorization:

• If groups are selected, only their members and platform administrators can use the resource. Selecting no groups makes it available to all users.
• After an agent's access is restricted, excluded users can still view previous conversations but cannot send further messages.
• Skills do not currently have separate group-based permissions. Table Comments (Platform Fallback) is isolated by database connection rather than user group.

Check authorization before deleting a group: An agent or knowledge base authorized only for that group may become available to everyone. Adjust resource scopes first, following the interface guidance.

6. Configure Agents and Skills

An agent is an assistant configured for a task. A skill contains instructions for handling a particular type of task.

1. In Skills, upload a standard ZIP skill package containing SKILL.md, review it, and enable it.
2. In Agents, edit the assistant's purpose, default model, bound skills, searchable knowledge bases, and default execution policy.
3. Select the required tools under Available Tools. Clear tools for tasks that should not be allowed.
4. Set the access scope as described in Manage User Groups and Access Scopes, then create a conversation to verify it.

Skill activation: An uploaded skill must also be bound to an agent. Built-in skills are updated with platform releases.

Tool scope:

• All available tools are enabled by default, including tools added later. Review the list after upgrades.
• Disabled tools are not provided to the model, and attempts to call them are rejected.
• Tools marked Data Egress send data outside the platform. Disable the forecasting tool for agents that must not perform forecasting.

Verification: Confirm the assistant uses the expected model, skills, knowledge bases, and tools, and that excluded accounts cannot use it.

7. Manage Knowledge Bases

7.1 Create and Verify

1. Open Knowledge Base → Create Knowledge Base → Upload Document.
2. In Documents, wait for Parsing to change to Searchable. Resolve failures according to the reason displayed.
3. Use Search Test to check matches and sources. Click Surrounding Context to view adjacent passages.
4. Bind the required knowledge bases in Agents and restrict user groups through Access Scope.
5. Ask a question using an actual user account and verify the citations.

7.2 Files and Scanned Documents

Item	Requirement
Formats and size	.txt, .md, .csv, .pdf, .docx; at most 30 MB per file by default. Save legacy .doc files as .docx first
Scan recognition model	Uses the default model, which must support image understanding; recognition counts toward model usage
Scanned pages	At most 20 pages; exceeding the limit causes parsing to fail. Split the document before uploading
PDFs with both text and scanned pages	Only text pages may be extracted. Confirm that the required content was parsed

7.3 Updates and Access

• Upload with the same name: Replaces the previous version after successful parsing. If parsing fails, the previous version remains searchable.
• Interrupted parsing: Documents still being parsed during a service restart are marked failed and must be uploaded again.
• Deletion: Check the scope of impact before deleting a document or knowledge base.
• No knowledge bases bound: The agent can search all knowledge bases available to the current user, without bypassing group permissions.
• System knowledge base: Do not rename Table Comments (Platform Fallback). Users can retrieve only content within their own database Context scope.

8. Configure External Tools (MCP)

External tools connect to other systems, such as ticketing or notification services. An administrator must register the service and enable it for the agent first. The service must be permitted by your organization and reachable from the backend.

1. Open External Tools (MCP) → Register MCP Service.
2. Enter the name, tool-name prefix, service URL, optional Authorization information, and timeout.
3. Save and inspect the tool list. If retrieval fails, the configuration is still saved with a failure reason. Correct it and click Refresh.
4. Edit the agent and enable the service under External Tools (MCP).
5. Create a conversation, try an allowed operation, and check approval and audit records.

Registration requirements:

• Only http/https URLs using Streamable HTTP are supported. The tool-name prefix cannot be changed after registration.
• Authorization information is encrypted and subsequently shown only as Configured. Re-enter it if the platform encryption key is changed or lost.

Calls and disabling:

• Calls send arguments to the external service, require user approval, and create Data Egress records. Users can remember approval for the same tool within a conversation.
• Disabling a service prevents every agent from calling it.
• Registration, modification, refresh, and deletion also create audit records.

Deployment limits: To restrict registered service hosts or disable all external tools, ask operations staff to configure the settings in Common Configuration. TimechoAgent cannot currently serve tools to external clients as an MCP server.

9. Maintain Shared Memory, Usage, and Platform Status

Area	Actions and checks
Shared memory	Maintain shared conventions and preferences in Memory, check sources and currency, and do not store personal secrets. Regular users maintain their personal memories
Overall usage	Summarize by model, date, agent, and user in Usage Statistics. Regular users and database administrators see only their own usage. Estimated Portion represents character-based estimates when the provider did not return exact usage
Database channels	Execution Channels → Probe Again; confirm connectivity and version
System self-check	Ask operations staff to inspect the results. Resolve errors first and investigate warnings. Keep demonstration mode disabled in production
Separation of approval	Use Common Configuration to limit dangerous approvals to database administrators or enable four-eyes approval so another person also approves ordinary writes
API tokens	See API Tokens and Integration for centralized management