How teams should design agentic workflows
Agentic work is useful when a request has to become a routed plan with tools, checks, approvals, and a concrete output. The design goal is controlled execution, not raw autonomy.
Start with the work shape
A strong workflow names the task, the context required, the tools allowed, the approval points, and the artifact that should exist at the end. Without those boundaries, an agent can look busy while producing work that nobody can safely use.
In Kendr, agentic workflows sit beside deep research and knowledge bases so the system can reason from retained context before it acts.
The goal is not to remove humans from the work. The goal is to remove unnecessary coordination overhead while keeping judgment, review, and approval in the right places. A team should be able to see what the agent is trying to do, what information it is using, what tools it might call, and where it needs permission before changing anything important.
Agentic workflows become valuable when work has shape. "Fix our infrastructure" is too broad. "Inspect the failed deployment, compare it to the last successful release, summarize likely causes, and prepare a rollback-safe plan" is a workflow. It has context, sequence, tool needs, and a reviewable output.
Workflow ingredients
- Intake: capture the request, goal, environment, and success criteria.
- Context loading: attach repositories, documents, prior research, and project memory.
- Planning: split the work into visible steps with risk and dependency notes.
- Tool routing: call only the skill packs and MCP servers relevant to the task.
- Approval control: gate side-effecting actions such as deploys, writes, deletes, and credential-sensitive operations.
- Artifact output: finish with a plan, pull request, report, runbook, or decision trail.
These ingredients should be explicit because they make the workflow easier to improve. If the output is weak, the team can ask whether the intake was underspecified, the context was missing, the tools were wrong, or the approval boundary was unclear. That is much easier than trying to debug a single opaque agent response.
A practical workflow lifecycle
An agentic workflow should have a lifecycle that a team can recognize. Kendr workflows can be light, but they should still move through clear phases.
- Request: capture the job, owner, target system, and expected deliverable.
- Context: load relevant files, docs, tickets, repositories, knowledge-base entries, or previous research runs.
- Plan: break the work into steps and identify what can be done safely without approval.
- Execute: run read-only checks, analysis, generation, or safe local changes.
- Approve: stop before side-effecting actions and ask for explicit human confirmation.
- Deliver: produce the final artifact with assumptions, evidence, and next steps.
- Retain: save the important context so future runs do not repeat discovery work.
This lifecycle is useful for technical and non-technical workflows. A cloud remediation workflow, a vendor review workflow, and a daily executive brief all need intake, context, output, and memory. The tools differ, but the operating discipline is similar.
Approval-aware execution
Approvals are not a tax on productivity. They are how agentic work becomes safe enough for teams to use in real systems. A workflow should clearly distinguish read-only actions from side-effecting actions.
Read-only actions might include inspecting logs, reading cloud inventory, summarizing tickets, reviewing repository files, or comparing documentation. Side-effecting actions include deploys, deletes, writes, billing changes, IAM changes, DNS changes, network updates, data exports, and anything involving credentials or secrets.
Kendr's value is strongest when workflows can prepare side-effecting work without silently performing it. The agent can gather evidence, produce a plan, draft a command, prepare a pull request, or explain a rollback path. The human can then decide whether the action should happen.
Design patterns for teams
Research to plan
Use deep research or local context review to understand the situation, then ask Kendr to turn the findings into a plan. This pattern works for architecture reviews, vendor evaluation, market analysis, and policy review.
Diagnose to remediation
Use read-only diagnostics to inspect a failure, then produce a remediation proposal that names risks and approval points. This works for incidents, CI failures, Kubernetes issues, cloud configuration drift, and cost waste.
Brief to recurring output
Turn a repeated information need into a workflow that gathers sources, summarizes changes, and produces a consistent deliverable. This works for executive daily briefs, market monitoring, customer updates, and internal operating reviews.
Memory to execution
Start a new workflow by loading project memory from prior research. This keeps the agent grounded in previous decisions, known constraints, and unresolved questions.
Example workflow prompts
Review the failed CI run and prepare a triage report. Use the repository, recent changes, workflow logs, and test output. Do not change files yet. Return: - most likely cause - evidence from logs or code - affected area - safe first fix - risks before making changes
Inspect this Terraform change before apply. Explain: - resources created, changed, or destroyed - IAM, network, storage, billing, and data risks - environment assumptions - approval questions for the reviewer - recommended plan if the change is approved
These prompts are useful because they specify tool posture. The agent is allowed to inspect and reason. It is not silently authorized to mutate production systems.
What to measure
Agentic workflows should be judged by output quality, reviewability, and time saved on repeatable coordination. A workflow that produces many steps but no trustworthy artifact is not successful.
- Clarity: can a reviewer understand what happened and why?
- Grounding: does the workflow use the right sources and project context?
- Control: are side-effecting actions gated?
- Repeatability: can the same workflow be used again with similar inputs?
- Memory: does the workflow improve future runs by saving durable context?
Mistakes to avoid
Do not start by automating the most dangerous part of the job. Start by automating context gathering, synthesis, comparison, and draft artifacts. Once the workflow is trusted, approval-gated execution can be introduced carefully.
Do not hide the plan. If an agent moves directly from request to action, the team loses the ability to correct assumptions early. A visible plan is a cheap way to catch the wrong environment, wrong branch, wrong document set, or wrong success criteria.
Do not treat every workflow as a one-off. If the task will happen again, preserve the workflow shape, the prompt, the source expectations, and the output format. Repeatability is where agentic work starts to compound.
Where Kendr fits
Kendr is strongest when a team wants to move from research into action without losing context. Architecture reviews can become phased plans. Cloud diagnostics can become approved remediation steps. CI failures can become triage notes and next changes.
Measure the workflow
The right question is not whether an agent completed many steps. The right question is whether the workflow produced something reviewable, repeatable, and grounded in the team's actual context.
A useful Kendr workflow should leave behind a record that another teammate can read. It should explain the request, what context was used, what actions were taken or proposed, what was intentionally not done, and what should happen next. That record is the bridge between AI assistance and team operations.
When teams build workflows this way, agentic systems become less mysterious. They become a disciplined way to turn research, context, and tools into reviewable work.