Decide which steps need a model, which need rules and where a person should review the result. A practical framework without an assumed 80/20 ratio.
By AppsTango Engineering · Content reviewed
Use explicit validation and workflow logic where the task is defined.
Test whether a bounded model step adds useful interpretation.
Set permissions and decide which actions need confirmation.
Measure errors, completion, latency and cost before expanding.
An illustrative decision framework; the answer can differ for each step of a workflow.
“We need an AI agent” is a proposed implementation. Start one step earlier: what does the user need to accomplish, what information is available, and what should happen if the system is wrong?
The answer may be a form, a rules-based workflow, a model-assisted step or an agent with bounded tools. This is a decision framework, not a measured claim about the percentage of ideas we reject.
Write down the starting event, available information and expected result. Separate structured inputs, such as a set of required fields, from variable inputs, such as an open-ended document or message.
Check whether the task can be completed with explicit rules. Rules can be tested against known cases and are often a useful baseline even if a model is added later.
A model may help summarize varied text, draft content or interpret a request that does not arrive in a fixed format. Evaluate that step on representative examples. A fluent answer is not evidence that the workflow completed correctly.
Keep retrieval, permissions and writes explicit. A model suggesting an action is different from a system being authorized to perform it.
List the consequences of an error. For each proposed action, decide whether it can run automatically, needs confirmation or should remain with a person. The decision depends on the data, reversibility and impact of the task.
Plan for uncertainty and service failures. Define a useful fallback, a review queue or a request for missing information instead of an unbounded retry loop.
Create examples of acceptable and unacceptable results, including difficult cases. Measure completion, errors, latency and usage cost during a bounded pilot. Keep the model, prompt and tool versions with the test results.
For Amazon Bedrock, rates vary by model and usage mode; check the current pricing when estimating the pilot. A spend limit and observation of actual usage are more useful than assuming each conversation costs the same.
The 80/20 Hybrid is shorthand for reusable foundations plus senior judgment. It does not prescribe a code ratio or a rejection rate for AI ideas.
Before commissioning an agent, bring a sample input, the desired output, the tools it would need and the consequences of a wrong result. Our AI agents service discussion starts there. The first objective is to choose a testable workflow and a sensible next step.
# keep-reading
Prepare the build, reviewer access, metadata and privacy information before submission. Approval and review timing remain Apple’s decisions.
Authentication, billing, monitoring, delivery and infrastructure patterns to review before launch. Reuse can reduce repeated work; cloud savings must be measured.
$ your next step
Bring an example input, the desired result and the cost of an error. A free 30-minute strategy call covers scope, budget and the next step.