Skip to main content
Context documents let you give agents access to reference material stored in Google Docs or Notion. This is perfect for runbooks, policies, procedures, contact lists, and other static knowledge that agents should reference.

What Are Context Documents?

Context documents are external documents (Google Docs or Notion pages) that:
  • Are automatically fetched and loaded at agent runtime
  • Provide reference material the agent can consult
  • Are maintained by humans outside of Cotool
  • Stay in sync with your source of truth
Think of context documents as the agent’s reference library - manuals, runbooks, and knowledge bases it can consult.

Examples

Runbooks & Procedures

Standard operating procedures for common scenariosExample: “How to respond to ransomware alerts”

Known False Positives

Lists of known false positives to avoid re-investigatingExample: “Approved admin tools that trigger alerts”

Contact & Escalation Info

Who to contact for different scenariosExample: “Security team on-call rotation”

Policies & Requirements

Compliance requirements and organizational policiesExample: “Data handling requirements for PII”

Glossary & Terminology

Org-specific terms and definitionsExample: “Our product names and what they do”

Historical Context

Background on recurring issues or past incidentsExample: “Known infrastructure quirks”

Adding Context Documents

1

Prepare Your Document

Create a Google Doc or Notion page with the reference materialTips:
  • Use clear headings and structure
  • Keep focused on one topic per document
  • Update regularly
2

Make Document Accessible

For Google Docs: Share with “Anyone with link can view”For Notion: Make page public or share with Cotool integration
3

Add to Agent

In agent configuration:
  1. Click “Add Context Document”
  2. Select source (Google Docs or Notion)
  3. Paste document URL
  4. Add description (what’s in this doc)
4

Test

Use Builder to verify agent can access and use the document

Document Format Best Practices

Structure

Use clear hierarchy with headings:
# Security Alert Runbook

## Critical Alerts

### Ransomware Detection
- **First steps**: Isolate affected endpoints immediately
- **Evidence to collect**: Memory dump, process list, network connections
- **Escalation**: Page on-call security manager

### Data Exfiltration
- **First steps**: Block outbound connections
...

Keep It Scannable

Agents work best with structured, scannable content: Good:
## Known False Positives

**IT Admin Tools**:
- `C:\AdminTools\PSExec.exe` - Used for remote management
- `C:\Scripts\Backup.ps1` - Nightly backup script
- Contact: it-team@company.com if questions

**Developer Tools**:
- Any activity from `devops_service_account`
- Debuggers in development environment
Bad (too narrative):
So there's this tool that the IT team uses sometimes, 
it's called PSExec and it's located in the AdminTools 
folder, and sometimes it triggers alerts but that's okay...

Use Lists and Tables

Agents parse structured data better than prose: Tables for reference data:
TeamOn-CallEmailEscalation
Security@johnsec@co.comCISO
IT Ops@janeops@co.comIT Director
Lists for procedures:
  1. Check alert severity
  2. Search logs for related activity
  3. If confirmed threat, isolate endpoint
  4. Notify security team

Include Examples

Show the agent what good looks like:
## Jira Update Format

Use this format:

**Good example**:
Severity: Critical
Evidence: VirusTotal 15/70 vendors flagged as ransomware. Observed file encryption behavior.
Recommendation: Isolate endpoint immediately.

**Bad example**:
This looks bad, probably should isolate.

Document Size Limits

Limits:
  • Max 50KB per document (plain text equivalent)
  • Up to 10 documents per agent
  • Total context budget: ~200KB (includes prompt + docs + memories)
If you hit limits:
  • Split large docs into focused topics
  • Use summaries instead of full detail
  • Consider using memories for dynamic data instead

Sync and Freshness

How syncing works:
  • Documents are fetched fresh for each agent run
  • Changes in Google Docs/Notion appear immediately
  • No manual sync needed
Best practices:
  • Keep docs updated as procedures change
  • Note last update date in document
  • Review docs quarterly for stale info

Real-World Examples

Example 1: False Positive List

Google Doc: “SentinelOne Known False Positives”
# Known False Positives - SentinelOne Alerts

Last Updated: 2025-10-15

## IT Administration Tools

### PSExec (Sysinternals)
- **Hash**: a4b2c3d4e5f6...
- **Path**: C:\AdminTools\PSExec.exe
- **Reason**: Used for remote system administration
- **Approved by**: Ticket CHG-1234
- **Contact**: IT Ops team

### PowerShell Scheduled Tasks
- **Pattern**: PowerShell scripts in C:\Scripts\
- **Schedule**: Daily at 2am
- **Reason**: Automated backups and maintenance
- **Contact**: DevOps team

## Development Tools

### Visual Studio Debugger
- **Process**: vshost.exe, devenv.exe
- **Environment**: Dev workstations only
- **Reason**: Legitimate development activity

## When to Ignore These FPs

- Only on approved systems (see list below)
- During business hours (or scheduled maintenance)
- If signature hash matches exactly

If activity deviates (wrong time, wrong system), investigate further.

## Approved Systems for IT Tools

- ADMIN-01 through ADMIN-05
- DEVOPS-VM-*
How agent uses it:
In system prompt:

Before classifying an alert as malicious, check the context 
document "Known False Positives" to see if this is approved 
activity. If the file hash, path, and system match the FP list, 
classify as False Positive and reference the ticket number.

Example 2: Contact Directory

Google Doc: “Security Team Contacts”
# Security Team Contacts

## On-Call Rotation

**Primary**: 
- This week: John Smith (@john in Slack)
- Email: john@company.com
- Phone: +1-555-0100

**Backup**:
- This week: Jane Doe (@jane)
- Email: jane@company.com

## Escalation Paths

### Critical Incidents (SEV-1)
1. Page on-call via PagerDuty
2. Post to #security-incidents
3. Escalate to CISO: ciso@company.com

### High Severity (SEV-2)
1. Slack on-call in #security-alerts
2. Create incident ticket
3. If no response in 15 min, escalate to backup

### Medium/Low
1. Create ticket
2. Post in #security-alerts
3. No immediate page needed

## Team Specializations

- **Malware/Endpoint**: John, Sarah
- **Network/Infrastructure**: Mike, Lisa
- **Cloud Security**: Alex, Jordan
- **AppSec**: Chris, Taylor

## External Contacts

- **Legal/Privacy**: legal@company.com
- **Compliance**: compliance@company.com
- **PR/Comms** (for breaches): pr@company.com
How agent uses it:
In system prompt:

When escalating alerts, reference the "Security Team Contacts" 
document for current on-call and escalation procedures. 
Use the severity-appropriate escalation path.

Example 3: Alert Response Runbook

Notion Page: “Ransomware Response Runbook”
# Ransomware Detection Response

## Immediate Actions (First 5 Minutes)

1. **Isolate affected endpoint(s)**
   - Use EDR containment feature
   - Block at network level if needed
   
2. **Stop spread**
   - Disable affected user account
   - Block suspicious IPs at firewall
   
3. **Alert**
   - Page on-call security
   - Post in #security-incidents
   - Create SEV-1 incident ticket

## Evidence Collection (First 15 Minutes)

Gather:
- Memory dump (if possible before isolation)
- Process list and network connections
- Recent file modifications
- Authentication logs

## Analysis Steps

1. **Identify ransomware family**
   - Check file indicators in VirusTotal
   - Look for ransom note
   - Identify encryption patterns

2. **Determine scope**
   - How many systems affected?
   - What data encrypted?
   - When did encryption start?

3. **Find patient zero**
   - First infected system
   - Initial infection vector (phishing, vuln, etc.)

## Recovery

- Do NOT pay ransom without exec approval
- Restore from backups (verify backup integrity first)
- Check with legal before any external communication

## Post-Incident

- Full incident report required
- Review and update detections
- Conduct lessons learned
How agent uses it:
In system prompt:

If you detect ransomware indicators:
1. Immediately reference "Ransomware Response Runbook"
2. Follow the immediate action steps
3. Include runbook steps in your Jira update
4. Escalate per runbook escalation procedure

Context Docs vs Memories

Choose the right mechanism:
Context DocumentsMemories
Maintained by: HumansMaintained by: Agents
Updated: ManuallyUpdated: Automatically during runs
Best for: Static procedures, contacts, policiesBest for: Dynamic data, learned patterns, state
Examples: Runbooks, FP lists, contactsExamples: Cached lookups, tracking state, learned FPs
Sync: Real-time from sourceSync: Stored in Cotool database
Rule of thumb: If humans maintain it, use context docs. If agents learn it, use memories.

Prompt Instructions for Context Docs

In your system prompt, tell the agent about context docs:
## Reference Materials

You have access to these context documents:

1. **"Known False Positives"**: List of approved tools that trigger 
   alerts. Check this before classifying as malicious.

2. **"Security Team Contacts"**: Current on-call rotation and 
   escalation procedures. Use for all escalations.

3. **"Alert Response Runbooks"**: Procedures for different alert 
   types. Follow these steps closely.

When referencing these docs, cite them in your output:
"Per the FP list, this is an approved IT tool (ticket CHG-1234)"

Troubleshooting

Check:
  • Is document URL correct?
  • Is document shared publicly or with Cotool?
  • For Google Docs: Is link sharing enabled?
  • For Notion: Is page published or shared with integration?
Check:
  • Is system prompt clear about when to use document?
  • Test in Builder - can you see document in context?
  • Is document too large (check size limits)?
  • Is relevant info buried deep in document?
Fix: Make documents more scannable with clear headings
Fix:
  • Split into multiple focused documents
  • Remove unnecessary detail
  • Use summaries instead of full text
  • Consider moving some data to memories
Fix:
  • Update source document (changes appear immediately)
  • Add “Last Updated” date in document
  • Set calendar reminders to review quarterly

Best Practices

Don’t create one massive document with everything. Split by topic:
  • Separate FP list from contacts
  • Separate runbooks by alert type
  • One procedure per document
Stale docs lead to bad agent decisions. Review regularly:
  • Update contacts when team changes
  • Update procedures when processes change
  • Note last review date in document
Create document templates for consistency:
  • Standard runbook format
  • Standard contact info format
  • Makes docs easier for agents to parse
When you update a critical document, test agent in Builder to verify it uses new info correctly
In agent description, note which context docs it uses and why: “Uses FP list to avoid re-investigating known tools”