Best Practices

The Agent’s in Blink Ops enables teams to define automation-ready agents tailored to specific roles, environments, and policies. Following these best practices will help ensure agents behave predictably, securely, and in alignment with organizational goals.

​

Prompts

Prompts are the primary way you instruct an agent on what to do. They are used throughout the Agent Builder to define roles, responsibilities, constraints, and tasks—not limited to these alone. A strong prompt provides clear, contextual, and actionable guidance, improving the agent’s accuracy, predictability, and relevance.

1. Be clear and outcome-oriented: Prompts should state a specific objective and define what success looks like. For Example:

   • “Classify this alert using MITRE ATT&CK and assign an escalation tier based on IOC matches.”

   • “Handle alert.” (Too vague—what does handling involve?)

2. Provide operational context: Include details about vendors, inputs, and decision criteria. For Example:

   • “Evaluate based on CrowdStrike telemetry and Okta logs.”
   • “Use the risk evaluation ability (workflow) to determine the risk level.”

3. Avoid ambiguity: State conditions explicitly to reduce variability in agent behavior. For Example:

   • “Escalate only if alert.priority is ‘High’ and the asset is tagged production.”

   • “Decide based on priority.” (Unclear what defines priority)

4. Use procedural, decision-oriented verbs: Start prompts with action words that align with decision-making, classification, or evaluation. For Example:

   • “Classify the alert…”
   • “Determine whether…”
   • “Summarize the investigation…”
   • “Evaluate the access request…”

5. Specify style and tone: Define how the agent should communicate: concise, technical, user-friendly, formal, etc. For Example:

   • “Respond with a concise, technical summary suitable for a ticket.”
   • “Summarize in plain language suitable for Slack.”
   • “Use JSON format with clear field names and short justifications.”
   • “Maintain a neutral and professional tone when declining access.”

​

Agent Configuration

​

Defining Roles

Define the agent’s role within your environment, including its primary responsibilities and any operational constraints it should follow. This helps shape how the agent behaves and interacts with your systems.

• Define responsibilities in business terms: Focus on what the agent is responsible for from an operational standpoint (e.g., “approves or denies privileged access requests based on risk”).
• Align with your security functions: Match responsibilities with real-world roles like “Access Reviewer,” “Alert Classifier,” or “Policy Auditor.”
• Keep the scope focused to simplify logic and maintenance.
• Avoid overloading: Limit the agent to a focused domain of responsibility to reduce complexity and promote maintainability.

​

Defining Constraints

• Outline what the agent should not do, by clearly defining any boundaries or constraints it must follow. This helps guide the agent’s behavior and ensures it operates within the intended limits of your environment.

​

Assigning Agent Abilities (Workflows)

Abilities determine what workflows an agent can access.

1. Follow least privilege: Grant only essential workflows.
2. Validate: Use a clear and descriptive name for the workflow. Include a concise description of its purpose, and ensure all inputs and outputs are clearly defined and well-documented.
3. Group by function: Align workflows to the agent’s domain (e.g., access control, alert triage).

​

Agent Tasks

​

Defining Tasks

Tasks describe the specific mission the agent must perform. They provide clear, actionable instructions based on a specific use case, for example a workflow’s logic and inputs. Unlike roles and responsibilities, which define what the agent is generally accountable for, tasks are precise and contextual.

1. Be contextual and execution-specific: Frame the task around the specific use cases goal.

   • Good: “Evaluate if the user’s access to production servers is valid based on location, time, and group membership.”

   • Bad: “Review access.”

2. Include all relevant inputs: Reference the data the agent should use in its decision-making (e.g., alert severity, source IP, user department).

3. Use domain-specific language: Tailor the phrasing to your security or operational use case so the agent understands the terminology and logic.

4. Keep the task narrowly scoped: One task = one decision, classification, or action. Break larger objectives into separate workflow steps if needed.

​

Structuring Agent Outputs

Consistent outputs simplify integration and auditing.

1. Define an output schema: Use consistent structures like JSON.
2. Include metadata: Capture fields like risk_level, decision_justification, or policy_violation.
3. Log identifiers: Include values like ticket_id, incident_id, or requestor.

Example Output:

{
  "decision": "deny",
  "risk_level": "high",
  "escalated_to": "SecOps_Tier3",
  "policy_violation": "Access requested outside approved hours"
}

​

Writing Instructions for Roles & Responsibilities vs. Tasks

When writing Roles & Responsibilities keep in mind

1. Behavior is relevant across multiple workflows.
2. You are defining a persistent capability or policy.
3. You want to clarify what the agent is accountable for long-term.
4. Roles & Responsibilities defines the agent’s core functional purpose (e.g., “access approver,” “alert triager”).

when writing Tasks keep in mind:

1. You are instructing the agent for a specific decision or action.
2. Workflow inputs require custom logic.
3. You want temporary behavior overrides.