> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Demonstration of Prompt Engineering Part 1
> Introduction to iterative prompt engineering using Amazon Bedrock, demonstrating techniques and constrained JSON outputs to produce consistent, machine‑readable classifications for IT support tickets
In this lesson we introduce prompt engineering with a short, practical demonstration you can reproduce in the Amazon Bedrock Playground. The goal is to move from ad-hoc, inconsistent prompts to a repeatable, measurable process that yields reliable, application-ready outputs.
What you'll learn
* The common pain point: developers wasting time on random prompts and inconsistent results.
* What prompt engineering is and the core techniques to apply.
* A hands-on demonstration in the Bedrock Playground showing iterative prompt improvements.
* The expected improvements and a concise summary to apply in your projects.
Jump in — we start with the problem.
## The problem: unstructured experimentation wastes time
Many teams iterate by randomly rewording prompts until something “sounds right.” Without a method to compare changes, it’s hard to know which tweak actually improved the result. Vague prompts produce vague results, and small wording changes can dramatically affect the output. Applying a structured, iterative approach reduces wasted cycles and produces consistent outputs suitable for downstream systems.
## What is prompt engineering?
Prompt engineering is the process of designing, testing, and refining prompts to get predictable, useful model outputs. It’s an iterative, measured approach:
1. Create a baseline prompt.
2. Observe outputs and identify gaps.
3. Modify the prompt to address those gaps.
4. Test again and repeat.
Foundation models (for example, those available through Amazon Bedrock) often follow instructions quite literally, so clarity — audience, role, constraints, and output format — matters.
Example:
* Weak: “Explain AWS security.”
* Engineered: “Explain AWS security to a non‑technical executive in five bullet points.”
The engineered prompt adds audience, context, and output constraints, making the response more predictable and actionable.
## Common prompt engineering techniques
Each technique can be used alone or combined to increase consistency and control.
| Technique | Purpose / When to use |
| - | - |
| Few-shot prompting | Provide 1–3 examples of desired inputs and outputs so the model learns the expected pattern. |
| Step-by-step instructions | Ask the model to follow explicit steps for complex tasks or multi-stage reasoning. |
| Role prompting | Assign a role (e.g., “You are a support operations assistant”) to frame tone and perspective. |
| Chain-of-thought | Encourage the model to reveal intermediate reasoning for difficult problems (use cautiously with strict output formats). |
| Output format specification | Require a specific schema or format (e.g., JSON) so outputs are machine-parsable and consistent. |
Remember: prompt engineering is iterative. Start simple, evaluate, and add constraints that solve observed weaknesses.
The iterative flow produces continuous, stepwise improvement in quality.
## Demonstration: classify IT support tickets in the Bedrock Playground
We’ll apply the techniques above in the [Amazon Bedrock Playground](https://learn.kodekloud.com/user/courses/introduction-to-amazon-bedrock). The use case: classify support tickets into categories and priorities, and return a short, standardized description.
Setup
* Open the [Amazon Bedrock console](https://learn.kodekloud.com/user/courses/introduction-to-amazon-bedrock) and go to the Playgrounds.
* Choose a model (for example, a Titan-family model available in Bedrock).
* Switch the Playground to single-prompt mode to evaluate prompts in isolation (no multi-turn state).
Use case specifics
* Categories: `billing`, `login`, `performance`, `security`, `general`
* Priorities: `low`, `medium`, `high`, `critical`
* Output: strict JSON matching your API schema so downstream services can parse it directly
Walkthrough — progressively constrain and improve the prompt:
1. Naive starting prompt
This is a minimal prompt many developers try first. It’s ambiguous and unconstrained.
```text theme={null}
Classify this support ticket:
"I cannot log in and I need access before a client meeting in 30 minutes."
```
Problems with this prompt:
* No role or audience.
* No constrained label set for categories or priorities.
* No machine-readable output format.
2. Add role/context
Adding a role primes the model for a practical, operational response.
```text theme={null}
You are a support operations assistant.
Classify the following support ticket:
"I cannot log in and I need access before a client meeting in 30 minutes."
```
Improvement: output will be more operational in tone, but field names and values still vary.
3. Constrain allowed labels (reduce freedom)
Specify the exact categories and priorities so the model must choose from them.
```text theme={null}
You are a support operations assistant.
Classify the following support ticket.
Use only these categories: billing, login, performance, security, general.
Use only these priorities: low, medium, high, critical.
Ticket:
"I cannot log in and I need access before a client meeting in 30 minutes."
```
With those constraints, the model is more likely to pick consistent labels.
Example model response (structured but not yet strictly machine-only):
```json theme={null}
{
"category": "login",
"priority": "critical",
"description": "User cannot log in and requires access before a client meeting in 30 minutes."
}
```
4. Constrain output format to strict JSON schema
If your system ingests the model output directly, require a precise JSON schema and instruct the model to respond only with that JSON and nothing else.
Final prompt example:
```text theme={null}
You are a support operations assistant.
Classify the following support ticket.
Respond only with valid JSON matching this schema:
{
"category": "one of [\"billing\",\"login\",\"performance\",\"security\",\"general\"]",
"priority": "one of [\"low\",\"medium\",\"high\",\"critical\"]",
"description": "string: a one-sentence summary"
}
Ticket:
"I cannot log in and I need access before a client meeting in 30 minutes."
```
Expected strict JSON output:
```json theme={null}
{
"category": "login",
"priority": "critical",
"description": "User cannot log in and requires access before a client meeting in 30 minutes."
}
```
That output is predictable and directly usable by downstream APIs or workflows.
## Practical tips and callouts
Start simple and iterate. Use role prompting, constrained label sets, and an explicit output format (for example, a JSON schema) to move from ambiguous, free-form results to consistent, machine-ready responses.
Additional recommendations
* Few-shot prompting: Include 1–3 annotated examples when you have representative tickets and desired outputs. This improves generalization.
* Chain-of-thought / step-by-step: Use when you need intermediate reasoning (e.g., triage logic), but avoid combining verbose chains-of-thought with strict machine-only outputs.
* Test consistently: Try prompts in the same Playground mode (single-prompt vs. multi-turn) to avoid behavior differences.
* Measure incremental changes: Add one constraint at a time and evaluate — this reveals which change caused the improvement.
## Summary and next steps
* Prompt engineering is an iterative, structured discipline that reduces ambiguity and produces reliable outputs.
* Key techniques: role prompting, few-shot examples, step-by-step instructions, chain-of-thought (when needed), and strict output format specification.
* In practice: begin with a simple prompt, observe the output, then incrementally add role context, label constraints, and an exact output format (JSON) to obtain application-ready results.
Further reading and references
* [Amazon Bedrock Playground](https://learn.kodekloud.com/user/courses/introduction-to-amazon-bedrock)
* [Kubernetes Basics](https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/) (for deploying systems that might consume model outputs)
* Consider logging prompt variants and results to measure improvements over time (A/B-style testing for prompts).
Future lessons will build on these foundations with more complex examples, evaluation metrics, and automated prompt testing strategies.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.