Creating a Managed Agent#
Managed agents are autonomous agents created on Lens Agents. You configure them through conversation — tell them what to do in natural language, and they learn your environment, preferences, and workflows.
Creating an Agent#
Managed agents are created on the platform with a name, a team, and a project. Teams determine the access grants and policies the agent inherits; projects scope which connections and credentials it can reach. Creation is available through the platform's web surface and through Slack DM to the Lens Agents bot — in both cases, as soon as the agent exists, the bootstrap conversation starts.
Bootstrap conversation#
Every new agent starts with a bootstrap conversation. The agent introduces itself and asks about your environment to configure itself:
Agent: Hi! I'm setting up. Tell me about your environment — what
systems do you work with, and what should I help with?
You: We run production on EKS with three clusters. I need you to
monitor pod health and alert me if anything goes wrong.
Agent: Got it. I'll focus on monitoring your EKS clusters. A few
more questions: What namespaces should I watch? How often
should I check? And where should I send alerts — here or Slack?
As you answer, the agent configures its own workspace files:
- Updates its Soul with personality and communication style based on your interaction
- Updates the User Profile with your timezone, priorities, and preferences
- Updates Heartbeat instructions with what to monitor
- Updates Vision with your goals for the agent
When the bootstrap is complete, the agent clears the bootstrap script and starts operating — heartbeat monitoring begins at the configured interval.
Agent Identity#
Each managed agent gets its own identity automatically:
- Dedicated token — auto-provisioned at creation, used for all API calls
- Team membership — inherits from the team selected at creation
- Project access — determined by the team's project grants
- Audit attribution — every action recorded under the agent's identity
Configuring after creation#
You can adjust your agent's behavior at any time through conversation:
Change monitoring focus:
Start monitoring the staging namespace too. Check for any pods using
more than 90% of their CPU limits.
Adjust autonomy:
Set your autonomy to level 4. I trust you to make configuration
changes without asking me first.
Update schedule:
Change your heartbeat to every 2 hours instead of every 8.
Set up scheduled tasks:
Run a compliance check every Monday at 9am.
Workspace files can also be edited directly through the platform's workspace editor.
Agent Lifecycle#
| State | Description |
|---|---|
| Bootstrap | New agent, running onboarding conversation |
| Running | Heartbeat active, responding to messages |
| Stopped | Heartbeat paused (manually or after 5 consecutive failures) |
Agents maintain continuity across sessions. Memory, workspace files, and conversation history are stored at the platform level — not in the sandbox. When the sandbox recycles, the agent picks up where it left off.
Session management: agent sessions reset daily (default: 4 AM local time). The timezone is configurable per agent. Idle timeout is optional and configurable per agent.
Conversation compaction: for long-running conversations, older messages are automatically summarized into a compaction summary. The most recent 20 messages are kept in full. This ensures the agent always has relevant context without exceeding token limits.
Step limits: each agent invocation can run up to 100 tool-use steps. If the limit is reached mid-investigation, the agent generates a final summary of all work completed and delivers it to you.
Default configuration#
New agents start with sensible defaults:
| Setting | Default |
|---|---|
| Autonomy level | 3 (Helper) — auto-approves low-risk actions |
| Verbosity | 3 (balanced) |
| Heartbeat interval | 8 hours |
| Timezone | UTC |
| Daily session reset | 4 AM (local timezone) |
| Step limit per invocation | 100 |
The default Soul template includes built-in safety boundaries: RBAC awareness, read-only by default, no credential hallucination, and privacy boundaries. You can customize these through conversation or the workspace editor.
Tool availability by mode#
Not all tools are available in every invocation mode:
| Tool category | Chat | Heartbeat | Scheduled task | Subagent |
|---|---|---|---|---|
| Workspace file updates (Soul, User Profile, Vision, etc.) | Yes | Yes | No | Yes |
| Memory (search, write, delete) | Yes | Yes | Yes | Yes |
| Scheduling (create, list, delete tasks) | Yes | No | No | Yes |
| Settings (autonomy, verbosity, heartbeat interval) | Yes | Yes | No | Yes |
| Infrastructure tools (shell, kubectl, AWS, GitHub) | Yes | Yes | Yes | Yes |
| Cost and audit tools | Yes | Yes | Yes | Yes |
| Subagent delegation | Yes | No | No | No |
LLM Configuration#
Managed agents use the following LLM configuration:
| Setting | Value |
|---|---|
| Primary model | Claude (via AWS Bedrock) |
| Classification model | Claude Haiku (for alert suppression and channel routing) |
| Temperature | 0.3 |
| Max output tokens | 16,000 per response |
| Step limit | 100 tool-use steps per invocation |
| Tool output truncation | 30,000 characters per tool call |
Prompt caching: stable sections of the agent's context (identity, workspace files, memory summary) are cached across invocations to reduce latency and cost. Dynamic sections (timestamp, heartbeat context, recent messages) are not cached.
When the step limit is reached, the agent generates a final summary of all work completed before stopping.
Related#
- Workspace files — the seven files the agent configures during bootstrap
- Autonomy levels — setting behavioral latitude as the agent matures
- Agent types — how managed agents compare to desktop and external modes