Skip to main content

How to use AI to improve text and validate data automatically

  • July 10, 2026
  • 0 replies
  • 2 views
vinicius.pereira
Community Manager

đŸ‘€  For pipe admins

🔐  Available on all plans

🎯  For those who have already created their first AI Agent and want to expand what the AI does

 

Once the first AI Agent goes into production, the natural question is: what else can the AI do? In practice, the answer is almost anything that involves interpreting text, extracting structured information or verifying whether a piece of data makes sense before advancing in the process.

This article presents five high-impact cases that any team can configure with the agent already created. Each case has the problem it solves, the example prompt and the most common pitfall. Choose the one closest to a repetitive task in your process and configure it today.
 

📖  What you will find here:

 

 

All the cases use the same structure as the previous article: trigger, instruction with dynamic fields and an action to update fields. What changes is the prompt. If you have not created the first agent yet, start there.

 

CASE 1

Improve and standardize text for external communication

The problem it solves

Requests arrive written in all sorts of ways: informal text, grammar mistakes, incomplete sentences. When that content needs to leave the process as a proposal, an email or an announcement, someone on the team rewrites it manually before sending.

The agent reads the original field and generates a rewritten version, with the tone and format you define, and saves it in a separate field. The original is preserved. The ready-to-use text goes to the output field.

 

Example prompt

Rewrite the content of the field [Request Description] in formal, professional language,suitable for sending to an external supplier.Criteria:- Correct grammar and punctuation mistakes- Keep all the original information, without adding data that was not mentioned- Use a neutral, objective tone- Limit the text to a maximum of 3 paragraphsSave the result in the field [Text to Send].

 

Most common pitfall

 

Do not ask the agent to "improve the text" without defining what better means. A formal tone for a supplier is different from an empathetic tone for a colleague. Specify the destination and the expected tone inside the instruction.

 

Create an output field separate from the original. Never have the agent overwrite the field where the user typed. Keeping the original preserves the history and makes revisions easier.

 

CASE 2

Extract structured information from free text

The problem it solves

Emails, open forms and descriptions arrive as a block of text. Inside that text are data points that need to go to specific fields: requester name, mentioned amount, deadline date, supplier tax ID. Someone reads and copies it manually.

The agent reads the text, identifies the data and fills in each corresponding field. The team receives the card already structured, without needing to do the extraction.

 

Example prompt

Analyze the field [Email Body] and extract the following information:- Full name of the requester → update the field [Requester Name]- Amount mentioned in currency → update the field [Request Amount]- Deadline date mentioned → update the field [Requested Deadline]If any information is not present in the text, leave the corresponding field blank.Do not make up data that is not explicitly in the email.

 

Most common pitfall

 

Without the instruction "do not make up data", the agent may infer or complete information that is not in the text. In financial or legal processes, this generates critical errors. Always instruct the agent on what to do when the information is not present.

 

Add an example inside the prompt when the expected format is specific. "The amount is always mentioned with the currency symbol followed by a number. Example: R$ 4,500.00" helps the agent identify the pattern more accurately.

 

CASE 3

Validate data before advancing in the process

The problem it solves

Required fields do not guarantee that the data entered makes sense. A tax ID field may be filled in with an invalid number. An email field may have an incorrect format. A description may be too vague for the team to work with.

The agent checks the data against a defined criterion, updates a status field with the result of the validation and, if necessary, moves the card to a review phase instead of letting the problem advance in the process.

 

Example prompt

Check whether the field [Request Description] meets the following criteria:1. Contains at least 30 words2. Clearly describes what is being requested3. Mentions the expected deadline or the justification for the requestIf all criteria are met:- Update the field [Validation Status] with the value "Approved"If one or more criteria are not met:- Update the field [Validation Status] with the value "Insufficient Information"- Update the field [Rejection Reason] explaining which criterion was not met- Move the card to the phase [Review by Requester]

 

Most common pitfall

 

Avoid subjective criteria without a reference. "Clear description" without a definition generates inconsistent results. Turn subjectivity into a measurable criterion: minimum number of words, presence of specific information, expected format.

 

Use the field [Rejection Reason] to close the loop with the requester. When the card goes back for review, the user already knows exactly what to fix, without needing to ask the team.

 

CASE 4

Summarize card comments and history

The problem it solves

Cards that go through several phases accumulate comments, emails and updates over time. When a new assignee takes over the card, or when a manager needs to assess the situation quickly, reading the entire history consumes time they do not have.

The agent reads the relevant fields of the card, produces a structured summary of the current state and saves it in a quick-read field. Whoever opens the card finds the context already consolidated.

 

Example prompt

Based on the fields [Request Description], [Recent Comments] and [Current Status],generate an executive summary of the card following this structure:- What was requested: (1 sentence)- Current situation: (1 to 2 sentences describing the most recent state)- Expected next step: (1 sentence with the pending action, if any)Use direct language. Do not repeat information. If there is no clear next step,write "Awaiting definition of next step". Save the result in the field [Executive Summary].

 

Most common pitfall

 

The agent only reads what you inserted as a dynamic field in the instruction. It does not automatically access the card's activity history. If the relevant context is in the comments, create a field that aggregates that content and insert it as a dynamic variable.

 

Define a fixed structure for the summary, as in the example above. Summaries without structure tend to vary in length and format between runs, which makes quick reading harder.

 

CASE 5

Classify and route automatically

The problem it solves

Requests arrive with no clear destination. Someone needs to read, decide which team it goes to and move the card manually. In high-volume operations, this creates a queue even before the work begins.

The agent analyzes the content of the request, determines the correct destination based on the criteria you define and moves the card to the corresponding phase. The team receives only what is theirs to work on.

 

Example prompt

Analyze the field [Request Description] and determine the responsible team:- If it mentions system access, equipment or technical support → IT team- If it mentions hiring, vacation, benefits or offboarding → HR team- If it mentions reimbursement, invoice, payment or budget → Finance team- If it does not fit any category above → Operations teamActions:1. Update the field [Responsible Team] with the determined team2. Move the card to the phase corresponding to the team

 

Most common pitfall

 

If the pipe phases have different names from the teams in the instruction, the agent may not find the correct destination. Use the exact phase names inside the prompt, the same way they appear in the pipe.

 

Always add a fallback category, like "Operations" in the example above. Ambiguous requests exist in any process. Without a fallback, the agent may take no action or classify randomly.

 

How to choose where to start

Five cases is more than a team needs to configure at once. The criterion for choosing the first is simple: which task consumes the most team time today because it is done manually?

  • Case 2 or Case 3 If the bottleneck is receiving disorganized information:
  • Case 5 If the bottleneck is deciding where each request goes:
  • Case 1 If the bottleneck is rework on external communication:
  • Case 4 If the bottleneck is internal alignment in long processes:

✅  Any of the five cases is solved in less than 30 minutes of configuration for someone who already has the pipe structured and the first agent created.

 

Before moving on, confirm that you have:

☐ Chosen the case closest to the real bottleneck of the process

☐ Created the output fields with descriptive names before configuring the agent

☐  Used dynamic fields in the instruction instead of typing the field name manually

☐  Included the instruction for the negative path (what to do when the criterion is not met)

☐  Checked the first cards in the Activities tab after activation

    Terms & ConditionsAccessibility statement