The Graph Modeler Agent
Part of the Zero to Operational for Amazon Neptune using Agentic AI series. This agent creates a graph model from your use case description.
This article is part of the Zero to Operational on Amazon Neptune using Agentic AI series.
Agent Goals
The next agent in our workflow is the Graph Modeling Agent. Here we provide the agent with a detailed use case description and it generates a graph model to solve it.
Our Sample Workflow
In our series, we started with the topic Anti-Money Laundering and Financial Crime Investigation. The Use Case Generator Agent created this use case from that topic, which we did not edit and will use as-is.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
<use_case>
Anti-Money Laundering and Financial Crime Investigation
</use_case><response>
Anti-money laundering and financial crime investigation involves tracking complex
webs of financial transactions across multiple accounts, institutions, and entities
to identify suspicious patterns that may indicate money laundering, fraud, or other
illicit activities. Graph databases are optimal for this use case because financial
crimes typically involve intricate networks of shell companies, intermediary accounts,
and circular transaction patterns that are designed to obscure the money trail.
Traditional relational databases struggle to efficiently analyze multi-hop relationships
and detect sophisticated layering schemes where money moves through numerous accounts
to distance it from its illegal source. Graph databases can rapidly traverse
transaction networks, identify unusual patterns like structuring or rapid movement
of funds, and uncover hidden connections between seemingly unrelated entities
through beneficial ownership, shared addresses, or transaction timing patterns.
Questions:
- Which accounts are participating in circular transaction patterns that could indicate layering activity in money laundering schemes?
- What are the shortest paths connecting a flagged high-risk entity to other accounts that received funds within a specific time window?
- Which shell companies or intermediary accounts appear most frequently in transaction paths between known suspicious entities?
</response>After passing this to our modeling agent, we get the following:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
{
"nodes": ["Account", "Entity", "Transaction", "Address", "FinancialInstitution"],
"edges": [
{
"label": "OWNS_ACCOUNT",
"from_label": "Entity",
"to_label": "Account"
},
{
"label": "BENEFICIALLY_OWNS",
"from_label": "Entity",
"to_label": "Entity"
},
{
"label": "HOSTED_AT",
"from_label": "Account",
"to_label": "FinancialInstitution"
},
{
"label": "REGISTERED_AT",
"from_label": "Entity",
"to_label": "Address"
},
{
"label": "TRANSFERS_FROM",
"from_label": "Transaction",
"to_label": "Account"
},
{
"label": "TRANSFERS_TO",
"from_label": "Transaction",
"to_label": "Account"
}
],
"properties": {
"Account": ["account_number", "account_type", "opening_date", "status", "balance"],
"Entity": ["name", "entity_type", "incorporation_date", "jurisdiction", "risk_level", "is_shell_company", "is_flagged"],
"Transaction": ["transaction_id", "amount", "currency", "timestamp", "transaction_type", "reference_number"],
"Address": ["street", "city", "country", "postal_code"],
"FinancialInstitution": ["name", "swift_code", "country", "institution_type"],
"OWNS_ACCOUNT": ["ownership_percentage", "start_date", "end_date"],
"BENEFICIALLY_OWNS": ["ownership_percentage", "relationship_type", "start_date", "end_date"],
"HOSTED_AT": ["account_status", "opening_date"],
"REGISTERED_AT": ["registration_date", "address_type"],
"TRANSFERS_FROM": ["timestamp"],
"TRANSFERS_TO": ["timestamp"]
}
}Just like before, we can use this as-is, or customize it manually before sending it to our next agent.
IMPORTANT: One current gap in this workflow and modeling schema is the lack of ability to effectively model when a label is shared across a node and edge, or when a given edge label can have different node labels it connects (e.g., if we used OWNS for both Entity to Entity and Entity to Account instead of OWNS_ACCOUNT and BENEFICIALLY_OWNS, respectively). The more complex JSON to do this seems to confuse the agents downstream. We currently address this in the prompt by having it generate unique label names, but may be able to better handle this in the future.
Agent Components
Let's look at the key components of the Graph Modeler Agent. The prompts shown here were tested with Anthropic Claude 3.7 and 4.0.
System Prompt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
Instructions: The customer will send you a description of the problem they want to solve using a graph and a series of questions they want the graph to answer.
Using the description and the questions, design a graph data model that should be able to answer their questions.
Definitions: Reification -- the process of making abstract concepts (like statements or relationships) into concrete, identifiable objects within a graph model. It essentially gives these abstract concepts a "physical" presence in the graph, allowing them to be queried and manipulated like any other entity.
Model:
The model shall contain:
- a list of node labels
- a list of edge labels with each showing the types of nodes they connect as a "from label" and a "to label"
- a list of properties for each label (nodes and edges).
Important Rules that must be followed:
- edges cannot have edges. These are refered to as hypergraphs and are not permitted. Use reification to create a node for an intermediary conceptual object and connect the edges to that conceptual object. Example: modeling "Person buys Item from Store" should create an intermediate node labeled "Purchase" because you cannot add an edge from another edge Buys to Store.
- each edge label should have a unique name. Do not use generic names like "HAS" nor reuse the same edge label for multiple "from_label" and "to_label" combinations.
# OUTPUT REQUIREMENTS
A JSON formatted representation of the model.
You MUST use this exact structure:
{
"nodes": ["NodeLabel1", "NodeLabel2"],
"edges": [
{
"label": "EDGE_LABEL",
"from_label": "SourceNode",
"to_label": "TargetNode"
}
],
"properties": {
"NodeLabel1": ["property1", "property2"],
"NodeLabel2": ["property3", "property4"],
"EDGE_LABEL": ["edgeProperty1", "edgeProperty2"]
}
}
# DO NOT
- Add any commentary or Markdown.Tools
None
User Message Template
1
2
Here is the description:
{description}What's Next
If you are just getting started building a graph solution on Amazon Neptune, create this agent using your favorite agentic AI framework (personally I use Strands Agents SDK ) and LLM and use it create a conceptual model for your graph. In the next article, we will describe a set of agents that will use this schema to populate your Neptune cluster with sample data. Have you implemented ways to improve this or have ideas on how to do so? Share them in the comments or reach out to me directly on LinkedIn .
Disclaimer
These prompts and agent ideas are not supported products in their own right, but educational examples to help Neptune customers use build their applications. Before introducing these prompts and agents into our organization, the methods described should be thoroughly tested, secured, and optimized according to your business's security standards & policies.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article