How to explore automation options in Buffaly
Buffaly can turn repeated work into something more durable, but the right form depends on the task. Start by describing the outcome, inputs, systems involved, approval points, and what would count as a correct result.
Choose the right automation boundary
| Boundary | Use when |
|---|---|
| Memory | Buffaly needs to remember a fact, alias, preference, contact, repository, document, or workflow phrase. |
| Prompt action | The work is a guided conversation, checklist, or repeatable reasoning workflow. |
| ProtoScript action | The task needs typed deterministic steps, native value flow, or reusable agent actions. |
| Native tool or service | The work needs compiled code, external APIs, high-volume data, strong typing, or service discovery. |
| MCP, web module, or provider module | The work connects Buffaly to an external tool, UI surface, or model provider. |
Practical promotion path
- Run the task manually with Buffaly once.
- Ask Buffaly to preserve the steps, evidence, risks, and validation checks.
- Remember useful aliases and facts first.
- If the workflow repeats, promote it to a prompt action or typed action.
- If it needs external access or deterministic code, use a tool, service, MCP binding, or provider module.
- Validate the new capability with a harmless first run before using it on real work.
Good first automation candidate: a recurring report, validation checklist, docs refresh, repository summary, or approval-gated draft that has clear inputs and acceptance criteria.
Verify before you automate
- Ask Buffaly to separate read-only steps from write or send steps.
- Require explicit confirmation before saving memories, sending messages, changing files, deploying, or updating external systems.
- Ask for validation checks and rollback options.
- Keep the first automation small enough that you can inspect the result.
- Use durable task artifacts for long-running or multi-step work.
Extension boundaries and semantic discovery
Extension boundaries should stay clear: memory stores facts and preferences, prompt skills capture repeatable judgment, ProtoScript actions expose typed Buffaly-native workflows, C# tools handle deterministic SDK or protocol work, services group configured capabilities, MCP bindings connect external servers, web modules add UI, and provider modules add model backends.
Semantic discovery makes new capabilities usable. A new action or entity needs clear names, descriptions, and infinitive phrases so Buffaly can find it from user wording, load the right tool, and verify the result. Always test discovery with realistic user requests after adding automation.
Examples, discovery, and verification
A good automation request names the repeated work, input source, output shape, and risk boundary. Buffaly should suggest the smallest useful capability boundary first, then verify semantic discovery with realistic user wording.
| Request | Likely boundary |
|---|---|
| Remember how I prefer release notes formatted. | Memory or prompt skill. |
| Load a CSV and show a grid preview. | ProtoScript action plus renderer/grid adapter. |
| Call a deterministic SDK or protocol. | C# DLL tool wrapped by ProtoScript. |
| Expose a model backend. | Provider module. |
After creating a capability, test discovery, loading, validation, and failure behavior before relying on it in a larger workflow.
Common mistakes
Automating before the manual workflow is understood
Run the workflow once, collect evidence, and define success before promoting it.
Using a code tool for a memory problem
If the issue is terminology, aliases, or preferences, remember the object first instead of building a tool.
Skipping validation
Every reusable capability should have a way to prove it worked.
Combining unrelated actions
Keep one automation focused on one workflow so it is safe to approve, test, and maintain.
Ask for options
Try: “Show automation options for this task. Separate memory, prompt-action, ProtoScript, native-tool, service, and integration approaches. Recommend the smallest safe first version.”