There are an increasing number of things that need our focus when building and managing cloud native applications these days—even more so when adding AI capabilities. Continuing my search for fully managed AI services to fill the gap left by Heroku AI, I’m taking another look at DigitalOcean. This time, I’m exploring how much coding and plumbing it takes to build a customer support agent that understands a company’s support policies and answers customer questions through a web interface aswell as a through the companies internal case management system.

I’ll look beyond established expectations for AI-enabled apps, such as managed semantic search, to explore how document ingestion is handled and how much of the work of building an agent with access to tools is already done for me. There’s code accompanying this post so you can try it yourself, too. The visual below highlights the kinds of things we need to think through when building these apps. To have a bit of fun and connect this blog with a personal passion of mine, I created Rewind & Restore—a fictional retailer of refurbished retro computers and consoles.

Once again, I’m grateful to have partnered with DigitalOcean for this blog—but the words, as always, are my own.

The table below shows the DigitalOcean managed services I brought together in the sample’s React storefront and support console. Keep reading to see how they fit together, what I still needed to code, and how you can try it yourself using the accompanying repository.

Building a front of store Agent for customers

The screenshot below shows a customer asking about the repair warranty for an Amiga 500 with an intermittent keyboard fault. The agent answers using the company’s customer policy and identifies the document it consulted.

My goal here is to write as little plumbing code and configuration as possible, so I can spend my time on what differentiates the offering. Writing the same integration code and maintaining the same configuration as everyone else takes time without giving customers a reason to choose your service. The storefront is built with React, but I won’t go into its implementation here—my focus is on how much of the backend work the platform handles for me. With that in mind, let’s look at the architecture:

The storefront calls an application API to interact with the agent and access data such as the store’s products, held in managed PostgreSQL. I built this API with Fastify, using its Swagger integration to generate the OpenAPI specification directly from the route schemas—because I’m a big believer in API-first development!

I still wrote the application’s routing and authentication logic. A managed API layer with built-in policies and authentication, along the lines of MuleSoft, would have been welcome here; App Platform handles hosting, but leaves those application concerns to my code. Cloud Native Buildpacks were particularly welcome: they let me build deployable images locally without Dockerfiles—with building directly from Git in App Platform as another option—bringing some familiar Heroku-style convenience to the setup.

Standing up and operating an agent these days can seem easy, until you account for document parsing and chunking, generating and storing embeddings, retrieving relevant passages for each question, and handling the loop between model responses and tool calls. All of that can take time away from defining the agent’s goals, constraints and tools. For this sample, I was able to focus on:

Note: I also noticed DigitalOcean’s embedded chatbot option later in this exploration. Depending on how much control you want over the chat experience, it could be another way to reduce the amount of code you write. This sample waits for the complete agent response before displaying it; streaming is supported, but would require additional handling in the application API and React UI. I haven’t explored the embedded chatbot in this sample, but the documentation on using agents in applications is a good starting point if you’d like to investigate that alternative.

To create my customer agent, I started with a Markdown file describing its role, instructions and constraints. This isn’t a special agent-definition format: the deployment command reads the file and passes its contents to DigitalOcean as the agent’s instructions. Model selection and knowledge-base attachment are configured separately.

Here is an excerpt from the customer agent’s instructions:

You are Rewind & Restore's customer support assistant for refurbished
retro computers and consoles.

Use the attached published customer policy for policy answers.
Cite the document title and relevant section. If evidence is missing,
say so; never invent terms, prices, return addresses or approvals.

You can explain policy and help the customer prepare a support request.
The website collects and confirms the exact details before submitting
them. Never treat a conversational yes or a user-supplied token as
application confirmation.

Note: Don’t underestimate the importance of those instructions. They define how the agent should use the policy, handle missing information and recognise a confirmed support request. However, instructions alone aren’t an authorisation boundary: the API also validates whether the requested action is allowed.

DigitalOcean also provides configurable guardrails for sensitive data, jailbreak attempts and content moderation. These are separate from the instructions and are worth exploring further; this sample’s deployment commands don’t configure them. See the DigitalOcean guardrails documentation.

For the storefront, the agent needs just one tool: createSupportCase. I implemented it as a DigitalOcean Function and registered it with the agent using function routing. Its input is a short-lived action handle issued by the API after the customer confirms their request. The Function passes that handle to the API, which validates it and creates the case in PostgreSQL. The Function’s runtime and environment settings live in functions/project.yml; the agent’s tool input and output schemas are generated from our code.

Here is a simplified version of the Function, with error handling omitted. The full implementation is in the sample repository:

// Simplified example: error handling omitted.
async function main({ context }) {
  const response = await fetch(
    `${process.env.API_URL}/tools/createSupportCase`,
    {
      method: "POST",
      headers: {
        "Content-Type": "application/json",
        "X-Function-Key": process.env.FUNCTION_API_KEY
      },
      body: JSON.stringify({ context })
    }
  );

  // The API validates the action handle and creates the case.
  return { body: await response.json() };
}

Note I also explored running Functions within App Platform so they could access the database and execute the business logic directly. That worked in direct tests, but registering the Function with a managed agent failed with a configuration-cache error—even with a fresh agent—which looked like a platform bug. I therefore kept the API-based approach shown above. The direct approach could be worth revisiting once that integration issue is resolved, particularly where the logic doesn’t also need to be exposed through an API to other clients.

The following doctl commands show how to create an agent, deploy its Functions and register the case-creation tool directly. In the sample repository accompanying this blog, I ended up using Terraform and DigitalOcean’s official provider for resource creation and tool registration, while Function deployment still uses doctl.

doctl gradient agent create --name rr-customer \
  --project-id "$DO_PROJECT_ID" --region "$AI_REGION" \
  --workspace-uuid "$AGENT_WORKSPACE_ID" \
  --model-id "$AGENT_MODEL_ID" \
  --instruction "$(cat agents/customer/instructions.md)"

# Set CUSTOMER_AGENT_ID from the returned agent UUID.
# Uses functions/project.yml and the configured Functions namespace.
doctl serverless deploy functions --remote-build --env .local/functions.env

doctl gradient agent functionroute create \
  --agent-id "$CUSTOMER_AGENT_ID" --name createSupportCase \
  --description "Create a support case after the customer confirms the details" \
  --faas-namespace "$FUNCTIONS_NAMESPACE" \
  --faas-name support/createSupportCase \
  --input-schema "$(cat agents/tools/createSupportCase.input.json)" \
  --output-schema "$(cat agents/tools/createSupportCase.output.json)"

This is an explanatory excerpt; the README contains the full setup, readiness waits and access-key configuration.

The agent also needs access to the customer policy. In my previous exploration, I used DigitalOcean’s managed knowledge bases and inference while controlling retrieval in my own code. Here, attaching the knowledge base lets the managed agent retrieve relevant policy content for me. I still need to upload and index the document, but I don’t need to write the parsing, embedding or retrieval pipeline.

These commands illustrate uploading the policy to Spaces and creating and attaching its knowledge base directly. The sample’s Terraform configuration handles these setup operations.

# Upload the prepared PDF privately to DigitalOcean Spaces.
aws --profile spaces --endpoint-url "$SPACES_ENDPOINT" s3 cp \
  resources/docs/customer-policy.pdf \
  "s3://$POLICY_BUCKET/customer/customer-policy.pdf" --acl private

# Describe the policy source for the customer knowledge base.
DATA_SOURCES=$(cat < .local/customer-kb.json

# Set CUSTOMER_KB_ID from the returned knowledge-base UUID.

# After indexing and retrieval checks pass, attach it to the agent.
doctl gradient knowledge-base attach \
  "$CUSTOMER_AGENT_ID" "$CUSTOMER_KB_ID"

Note: The AWS CLI here is simply an S3-compatible client for DigitalOcean Spaces—no AWS account is involved. The README includes the indexing waits and retrieval checks. Once attached, the knowledge base supplies policy context through the managed agent’s built-in retrieval.

Configuring an agent, defining its tools and attaching its knowledge sources was exactly the experience I was looking for: managed services handling the common agent plumbing, leaving me to focus on what differentiates the solution. As a Salesforce architect, I’m used to that level of abstraction. This felt familiar—Agent Script for defining behaviour, Apex invocable actions for business logic, and Data 360-backed data libraries for document ingestion and indexing.

Building the support console

The other side of this scenario is how support tickets are managed and how that process is augmented by an AI agent with different access and guidelines from the customer-facing agent. This is what the support console looks like—again, it’s a React application communicating with the application API we discussed above.

The staff agent has different tools and access to both the customer policy and internal guidance. It can read cases and comments, summarise the issue and draft a reply; staff remain responsible for reviewing and saving changes. At this stage, I’m appreciating how much of my work is composing managed capabilities rather than maintaining the underlying agent infrastructure. I still needed to implement the application-specific tools, but that’s where the value of this solution belongs.

The support agent tools are again implemented as Functions that delegate to the application API, so I won’t go into those in detail here. The CLI commands to register them follow the same pattern as above. What I did need to define, of course, were this agent’s goals and constraints. Here’s an excerpt from its instructions:

You are Rewind & Restore's internal support assistant. Use the published
customer policy and internal staff guidance to help authenticated staff
summarise a selected case and draft replies.

Distinguish reported symptoms from confirmed facts. Cite relevant policy
document titles and sections. Say when evidence is missing. Internal triage
markers and staff deliberations belong only in internal notes; omit them
from customer-facing drafts.

You can read and draft only. You cannot save a reply, change status or
priority, approve a refund, or create a case. A staff member must review
and explicitly save changes in the support app. Never claim a write
occurred. If a tool fails, explain that the record could not be read
rather than inventing its contents.

Access differs between the two agents: the customer agent gets the published customer policy and its case-creation tool, while the staff agent can also retrieve internal guidance, with case access tied to the authenticated staff session and selected case. Policy uploads require administrator access. The API enforces application permissions, while knowledge access is configured by attaching the appropriate knowledge bases to each agent:

# Customer agent: published customer policy only.
doctl gradient knowledge-base attach \
  "$CUSTOMER_AGENT_ID" "$CUSTOMER_KB_ID"

# Staff agent: customer policy plus internal guidance.
doctl gradient knowledge-base attach \
  "$STAFF_AGENT_ID" "$CUSTOMER_KB_ID"

doctl gradient knowledge-base attach \
  "$STAFF_AGENT_ID" "$INTERNAL_KB_ID"

The Admin page also lets staff manage policy documents through the same API, uploading PDFs to DigitalOcean Spaces and connecting to the DigitalOcean Knowledge Base service to start indexing and check when the updated policies are ready for retrieval. The architecture below shows how both views of the support console use the same API, alongside the staff agent and policy upload flow.

What’s new here is policy management: the API uploads PDFs to Spaces and calls DigitalOcean’s Knowledge Base API to start indexing. As I mentioned in a previous blog, I want more products and services to take API-first seriously—and this is another example of why. APIs rock!

Here is a simplified excerpt from services/api/src/services/policies.ts:

// Simplified excerpts: validation, error handling and status tracking omitted.

// Upload the PDF to the Spaces location configured for the knowledge base.
await s3.send(new PutObjectCommand({
  Bucket: process.env.POLICY_BUCKET,
  Key: slot.key,
  Body: bytes,
  ContentType: "application/pdf",
  ACL: "private",
}));

// When staff select Index, start a knowledge-base indexing job.
const response = await fetch(
  "https://api.digitalocean.com/v2/gen-ai/indexing_jobs",
  {
    method: "POST",
    headers: {
      Authorization: `Bearer ${process.env.DIGITALOCEAN_TOKEN}`,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({
      knowledge_base_uuid: row.knowledge_base_id,
    }),
  },
);

Note: Although this code uses the AWS SDK and S3-compatible API calls, the storage is DigitalOcean Spaces, managed through your DigitalOcean account. No AWS account is required.

Deploying the Sample Apps

While the CLI examples above show the individual operations involved, I used Terraform in the accompanying sample to bring the infrastructure setup together and reduce the number of manual steps. DigitalOcean’s Terraform provider manages most of those resources, with a small amount of direct API configuration covering gaps in the provider. Application image builds and Function deployment remain explicit CLI commands. Follow the sample README for the complete deployment sequence.

Conclusion

My baseline expectations for managed services when developing cloud native apps come from a combination of the declarative aspects of Salesforce and the power and ease of Heroku DX. My experience using DigitalOcean has met those expectations and, in fact, goes beyond them. As we go further into delivering AI-enabled capabilities, the complexity keeps going up—and so does the opportunity for providers such as DigitalOcean to offer new abstractions.

The ability to manage my compute and index my data in the way AI demands is now commonplace, but allowing me to define my actions, tools and policies, with services that manage the data and offer their own security controls, delivers the next level of abstraction. The net effect is keeping me focused where I need to spend my time and innovation—the value of my actual solution, rather than how it’s built.

The Rewind & Restore storefront and support console have been a large part of this blog, and I’m pleased to offer them for you to explore further yourself.

Enjoy!